3

I learnt from book (Expert C programming : deep C secrets" by Peter Van Der Linden ) that there are specific libraries for which dynamic linking is mandatory ; Which are these libraries ,and why they are mandatorily dynamically linked ? (more specifically on GNU/Linux system)

Onkar Mahajan
  • 944
  • 2
  • 13
  • 16
  • libnss is one of these, see http://stackoverflow.com/questions/2725255/getaddrinfo-is-not-statically-compiled – Ben Voigt Mar 14 '11 at 12:48

2 Answers2

2

Which are these libraries

All UNIX systems guarantee backward compatibility; that is, a binary built on an older system will continue to work and newer system. But this guarantee is only made for binaries which link with system libraries dynamically.

why they are mandatorily dynamically linked

The restriction is in place because user-level programs generally do not make direct system calls, but rather call libc wrapper routines. So a UNIX vendor is free to make incompatible changes to the syscall interface (e.g. to fix a bug), provided the system library is updated as well. Usually such changes only happen when upgrading to new OS release, e.g. from Solaris 2.6 to 2.7.

The picture on Linux is even more complicated than what I described above, because a single version of glibc is comprised of some 200+ separate binaries, which all must match exactly. Linking one such piece in statically, and then running on a system where other pieces do not match will produce unpredictable results; often a crash somewhere in libc.

Executive summary: never link UNIX system libraries statically into your executables, unless you know what you are doing and have a very good reason to do that.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
1

POSIX allows whether the dlopen and dlsym functions work as desired to be dependent on implementation-defined build conditions, and usually these conditions are either that the program must be dynamic-linked, or that if it's static-linked, that the equivalent of the -rdynamic linker option be used. So it's very possible that some libraries that depend on dynamically loading modules may only work in dynamic-linked programs, depending on your OS.

Aside from that, as long as you obey the requirements of the standards for a conforming program, there is no good reason static linking should not work with any library you want. If you start relying on hacks that replace standard functions with your own functions by the same name, then behavior may differ between static- and dynamic-linked versions of the same program. This is one manifestation of undefined behavior.

It should also be noted that glibc has a number of issues with static linking. Even when static-linked, programs using glibc dynamically load the libnss_*.so libraries for processing passwd file/NIS/DNS lookups/etc. There's also periodic breakage of static linking support in glibc. For instance I recently encountered failures in a glibc function that needed to know the pid/tid due to the thread descriptor for the main thread not being properly initialized in a static linked binary. If you want to use static linking on Linux, I would highly recommend choosing a non-glibc libc.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • This answer is correct in many details, but (IMHO) wrong in general: a program that statically links libc.a can not conform to POSIX requirements, as it no longer uses POSIX as its interface. It now executes direct system calls, and there are no standards for these to conform to. – Employed Russian Mar 26 '11 at 21:01
  • 1
    A dynamic-linked program does not meet your stringent definition of "[using] POSIX as its interface" either. For example `pthread_cleanup_push` and `errno` are both macros that expand to reference implementation-defined symbols in the libc. And in the case of glibc, all the `stat`-family functions get replaced to calls to `__xstat` or something with `struct stat` versioning. In any case POSIX is a *source* interface standard, not a binary interface standard. An implementation using static linking is just as valid as one using dynamic linking. – R.. GitHub STOP HELPING ICE Mar 27 '11 at 00:39
  • "An implementation using static linking is just as valid ..." -- true on the system on which it was produced; false on any different system. Which is a good reason to avoid static linking most of the time. – Employed Russian Mar 27 '11 at 06:01
  • 1
    This depends on how you define "system", and you seem to have some unconventional definition. In almost all real-world situations, a static-linked binary will run on a much wider variety of systems than a dynamic-linked one. – R.. GitHub STOP HELPING ICE Mar 27 '11 at 08:08