[gijoe77]

Hi all,

I'm not really sure how to ask this question, so I might just ask in a confusing manner, but when building software is there a real advantage nowadays to build it to use shared libraries or is it better off to build statically?  I was thinking about this as I just installed nekoware's git to test it vs my own build, and there was a bunch of other dependencies I had to install, I was wondering if building it statically would of saved some headaches?  I used to hear how building stuff to use shared libraries saved HDD space but this was in the days when HDD was scarce.  I guess what I want to ask is what is the real penalty for building static binaries?  Does anyone have a general rule of thumb on this topic?

also, when building a static binary, whats the prefered way to do it?  I saw in some configure scripts a "--disable-shared" and "--enable-static", and googling around I saw one can do LDFLAGS=-static, but to be very honest I haven't really playe much with it.

Would Nekoware's dependency issues on various packages have been "better" if the packages had been build statically?

Thanks again y'all for putting up with my newb/RTFM type questions

[Raion]

I tend to build certain files as static if they are specific utilities i.e a shell or sudo just in case IRIX decides to fuck up and overwrite the wrong library

[dexter1]

Static archives have the advantage to be self-contained and tend to run a bit faster than programs with dynamically linked libraries.

However:
1) Programs with statically linked libraries are much larger in size and waste memory when running multiple programs each having a static copy of the same library. With shared libraries and a linker program, you only have to have one copy of each library code and only runtime memory storage needs to be separated.

2) You can have multiple versions of a library next to each other, and can choose to link versions either by version suffix, like Linux is doing, or a version string embedded in the library, like IRIX.

3) Bugfixes and security patches are easy with shared libraries. You only have to install a new copy of the library and the linker will take care of running the newly patched library against your programs. Programs with statically linked libraries each have to be recompiled in order to fix bugs and security problems.

I hope this makes things clear. There are cases in which a statically linked program is preferred:
- It is safe from linking an unsafe library against a program to compromise data by means of 'stubbing' results or even functions.
- If you have a program which is essential to using the OS but needs to satisfy its dynamic dependencies to run, you can get into a catch-22.
F.I. this is why i have added a wget-static to the neko_wget package and in combination with the nekodeps script you can still download all libraries and programs

[jpstewart]

also, when building a static binary, whats the prefered way to do it?  I saw in some configure scripts a "--disable-shared" and "--enable-static", and googling around I saw one can do LDFLAGS=-static, but to be very honest I haven't really playe much with it.

To build a static binary, I'd use both the '--disable-shared' and '--enable-static' options to configure to make sure it does the right thing.  Depending on what's being built, configure may do a lot more than just adding '-static' to LDFLAGS.

Also note that to build a truly static binary, all the necessary libraries must be available as static libraries (libfoo.a) instead of shared (libfoo.so).  Sometimes you'll get a mixture of static and shared libraries used, no matter what.  See the 'ld' man page for details on what happens if it looks for static but can only find shared and vice versa.  I can't remember off hand when it'll fall back to the other and when it'll just fail.

Often when building libraries I'll use '--enable-static --enable-shared' on the configure command line to ensure that both types of library are built for future use.