Why is statically linking glibc discouraged?

Question

Most of the sources online state that you can statically link glibc, but discourage from doing so; e.g. centos package repo:

The glibc-static package contains the C library static libraries
for -static linking.  You don't need these, unless you link statically,
which is highly discouraged.

These sources rarely (or never) say why that would be a bad idea.

Solution 1

The reasons given in other answers are correct, but they are not the most important reason.

The most important reason why glibc should not be statically linked, is that it makes extensive internal use of dlopen, to load NSS (Name Service Switch) modules and iconv conversions. The modules themselves refer to C library functions. If the main program is dynamically linked with the C library, that's no problem. But if the main program is statically linked with the C library, dlopen has to go load a second copy of the C library to satisfy the modules' load requirements.

This means your "statically linked" program still needs a copy of libc.so.6 to be present on the file system, plus the NSS or iconv or whatever modules themselves, plus other dynamic libraries that the modules might need, like ld-linux.so.2, libresolv.so.2, etc. This is not what people usually want when they statically link programs.

It also means the statically linked program has two copies of the C library in its address space, and they might fight over whose stdout buffer is to be used, who gets to call sbrk with a nonzero argument, that sort of thing. There is a bunch of defensive logic inside glibc to try to make this work, but it's never been guaranteed to work.

You might think your program doesn't need to worry about this because it doesn't ever call getaddrinfo or iconv, but locale support uses iconv internally, which means any stdio.h function might trigger a call to dlopen, and you don't control this, the user's environment variable settings do.

And if your program does call iconv, for example, then things get even worse, especially when a “statically linked” executable is built on one distro, and then copied to another. The iconv modules are sometimes located in different places on different distros, so an executable that was built, say, on a Red Hat distro may fail to run properly on a Debian one, which is exactly the opposite of what people want from statically linked executables.

Solution 2

The program/glibc interface is standardized and documented by POSIX, the C and C++ standards, and others. For example, the fopen() function behaves per the C standard, and pthread_mutex_lock() per POSIX.

The glibc/kernel interface is not standardized. Does fopen() use open() under the hood? Or does it use openat()? Or something else? What will it use next year? You don't know.

If the glibc/kernel interface changes, a program that uses whatever changed but statically links glibc won't work any more.

15+ years ago, Solaris removed all static versions of libc for this very reason.

Static Linking - where did it go?

With Solaris 10 you can no longer build a static executable. It's not that ld(1) doesn't allow static linking, or using archives, it's just that libc.a, the archive version of libc.so.1, is no longer provided. This library provides the interfaces between user land and the kernel, and without this library it is rather hard to create any form of application.

We've been warning users against static linking for some time now, and linking against libc.a has been especially problematic. Every solaris release, or update (even some patches) has resulted in some application that was built against libc.a, failing. The problem is that libc is supposed to isolate an application from the user/kernel boundary, a boundary which can undergo changes from release to release.

If an application is built against libc.a, then any kernel interface it references is extracted from the archive and becomes a part of the application. Thus, this application can only run on a kernel that is in-sync with the kernel interfaces used. Should these interfaces change, the application is treading on shaky ground.

...

Edit:

There seems to be serious overestimation of the stability of the Linux kernel interface. See Linux kernel API changes/additions for details. To summarize:

Comments

[Maxim Egorushkin]

yarchive.net/comp/linux/gcc_vs_kernel_stability.html: We care about user-space interfaces to an insane degree. We go to extreme lengths to maintain even badly designed or unintentional interfaces. Breaking user programs simply isn't acceptable.

[Maxim Egorushkin]

unix.stackexchange.com/questions/235335/…

[Andrew Henle]

@MaximEgorushkin Reality is different. The Linux ABI isn't very stable, to the point it's been mocked relatively recently: "It's not a secret that there are two basic ways of running a Linux distribution on your hardware. Either you use a stable distro which has quite an outdated kernel release which might not support your hardware or you run the most recent stable version but you lose stability and you are prone to regressions."

[Maxim Egorushkin]

The quote you cited is about in-kernel driver APIs, not the user-space API.

[Andrew Henle]

@MaximEgorushkin Are you really claiming the the Linux kernel user-space API is standardized to the level of POSIX, the C standard, and the C++ standard, amongst others? Really? That the Linux kernel user-space API is as stable as standard C functions listed in the C standard? Because that is the interface that gets coded to.

[Maxim Egorushkin]

I never claimed that Linux API is standardized. Only that it is (relatively) stable. And most Linux POSIX function implementations are quite compliant.

[Andrew Henle]

@MaximEgorushkin I never claimed that Linux API is standardized. Only that it is (relatively) stable. Compared to POSIX and the C standard, it's not stable at all. It can be changed whenever a small group decides unilaterally to change it. The glibc interface is standardized. By POSIX. By the C standard. And others. So you admit this answer is correct then?

[Maxim Egorushkin]

Read my first two comments again and argue with Linus Torvalds.

[Andrew Henle]

@MaximEgorushkin That has absolutely nothing to do with static linking glibc. You need to read Richard Stallman about how its GNU (the G in glibc)/Linux and not just Linux. It's even got a wikipedia page.

[MSalters]

@AndrewHenle: That whole confusion is exactly why it's such a problem, even 25 years later. glibc tries to be too much for too many cases. Microsoft is much cleaner in this respect. Windows itself has the Universal CRT, Visual Studio has its MSVCRT.

[MSalters]

Note that the need for a second copy of glibc is a design decision. If the static glibc library had linked in NSS and iconv statically, it wouldn't have been necessary. The downside of course would be that you could only use those NSS modules and iconv conversions that were linked in statically, but that's pretty obvious from the definition of static linking.

[zwol]

@MSalters There has been some discussion recently on the glibc development list about doing just that. This design decision was made in the 1990s, and there's a strong argument that we don't need quite so much flexibility in character encoding for terminal output anymore, especially not in the kinds of programs that people want to link statically. NSS flexibility is still important but there are alternative ways to handle that (e.g. nscd).

[plugwash]

"The glibc interface is standardized. By POSIX. By the C standard. And others." the programming interface is, but the binary interface is not!

[Andrew Henle]

@plugwash And that's why statically-linking glibc has some serious drawbacks. The binary interface can change a lot easier than what you called the "programming interface". That programming interface is defined by the C standard and POSIX among other standards. The kernel's binary interface is not standardized at all. The programming interface is tightly defined and standardized.

[vpalmu]

This is not quite right; I discovered that staticly linked C programs using stdio.h work with no libraries in /lib. The program I had to do this with was lilo.

[plugwash]

The kernel's binary interface is not standardised, but neither is glibc's binary interface.

[zwol]

@Joshua Did you try it with LANG set to a locale that requires use of an unusual character set?

[vpalmu]

@zwol: It just switches to LANG=C if it can't load the library. This behavior is necessary for early boot.

[Andrew Henle]

@plugwash The kernel's binary interface is not standardised, but neither is glibc's binary interface. Ummm, you sure about that? The C standard says the function is fopen( const char *file, const char *mode ); The platform ABI specifies the calling convention into the system-provided library, along with the C standard and POSIX. So, do you know what system call that fopen() call uses?

[Andrew Henle]

@plugwash Can you please provide the standard that Linux kernel system call interface is governed by?

[user253751]

@Joshua then it sounds like it will load the library, and another copy of glibc, if it can.

[user253751]

Linux is committed to keeping its interface backwards compatible for this reason.

[user253751]

@AndrewHenle Actually, that's an argument in favour of static linking. What if the binary interface to glibc changed, but your program didn't change to use the new binary interface? (Answer: glibc doesn't change its binary interface for this reason)

[user253751]

@AndrewHenle The standard is here: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t‌​ree - unfortunately it's written in C rather than English.

[plugwash]

@AndrewHenle those standards are an insufficient specification of the interface for two reasons. The first is that C standard library functionality is sometimes implemented using macros. The second and far more pressing issue is symbol versioning, which effectively prevents software built against a newer glibc from running with an older glibc.

[Andrew Henle]

@plugwash Are you really trying to claim that statically linking to glibc 2.30 is the solution to producing a binary guaranteed to run on a system with glibc 2.21?

[Chris Dodd]

All the symbols that are statically linked from libc should override the symbols from any dynamically linked glibc in any uses from other dlopened dynamic libraries. So if you can ensure you get all the symbols needed by these libraries in your executable, it should not even end up dynamically linking a second copy. Of course if you miss any (easy to do), you'll get the extra copy.

[zwol]

@ChrisDodd If I remember correctly, the plugin's DT_NEEDED entry for libc.so.6 means the dynamic loader will load libc.so.6 even if all of its undefined symbols are satisfied by the executable.