Mandatorily Dynamically linked libraries

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

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.

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.