Take the 2-minute tour ×

On 'C', Linux,

Do I need static libraries to statically link, or the shared ones I have suffice? If not, why not? (Don't they contain the same data?)

share|improve this question
add comment

4 Answers

up vote 9 down vote accepted

Yes, you need static libraries to build a statically linked executable.

Static libraries are bundles of compiled objects. When you statically link with to library, it is effectively the same as taking the compilation results of that library, unpacking them in your current project, and using them as if they were your own objects.

Dynamic libraries are already linked. This means that some information like relocations have already been fixed up and thrown out.

Additionally, dynamic libraries must be compiled as position-independent code. This is not a restriction on static libraries, and results in a significant difference in performance on some common platforms (like x86).

There exist tools like ELF Statifier which attempt to bundle dynamically-linked libraries into a dynamically-linked executable, but it is very difficult to generate a correctly-working result in all circumstances.

share|improve this answer
Thanks for a great answer. But why is it so difficult? –  Liran Orevi Jun 20 '09 at 18:10
ELF Statfier loads the executable and all its libraries, then takes a snapshot of the process memory. When the output image is run, anything which would cause the memory layout to change (e.g. randomized VDSO) will result in incorrect operation. Any other approach requires re-inventing the dynamic linker. –  ephemient Jun 20 '09 at 19:00
Why would it be hard to reimplement the dynamic linker? Isn't there just two tables of the library's imports and exports, to be relocated? It's the linker, so it's already implementing a static linker, and it knows the file format of the executable and of the dynamic library, etc. –  ChrisW Jun 20 '09 at 19:12
The operations of the static (compile time) linker and the dynamic (runtime) linker are very different. The static linker rewrites references to symbols in objects to fixed references -- either to the relocated symbol within the same image, or to a stub that jumps to the correct entry in the symbol table. The dynamic linker opens files and maps them, with specific rules, to various parts of memory, fills in the symbol tables, and then jumps to initializing code. –  ephemient Jun 20 '09 at 19:42
add comment

There is no such thing as static compilation, only static linking. And for that, you need static libraries. The difference between static and dynamic linking is that with the former, names are resolved at link-time (just after compile-time), wheras with the latter, they are resolved just as the program starts running.

Static and dynamic libraries may or may not contain the same information, depending on lots of factors. The decision on whether to statically or dynamically link your code is an important one, and will often influence application architecture.

share|improve this answer
Thanks, corrected 'compile' to 'link'. –  Liran Orevi Jun 20 '09 at 18:06
add comment

All libraries you link into a statically linked program must be the static variant. While the dynamic (libfoo.so) and static (libfoo.a) libraries have the same functions in them, they are different format files and so you need the matching type for your program.

share|improve this answer
add comment

Another option is Ermine (http://magicErmine.com) It's like statifier, but able to deal with memory randomization.

share|improve this answer
Great product, thank you. –  Liran Orevi Jul 23 '09 at 21:30
add comment

Your Answer


