为什么不建议静态链接glibc? [英] Why is statically linking glibc discouraged?

问题描述

大多数在线资源表明您可以静态链接glibc，但不建议这样做；例如 centos软件包存储库:

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.

推荐答案

其他答案中给出的原因是正确的，但不是最重要的原因.

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

不应静态链接glibc的最重要原因是，它广泛使用了 dlopen ，以加载NSS( iconv 转化.模块本身引用C库函数.如果主程序与C库动态链接，那就没问题了.但是，如果主程序与C库静态链接，则dlopen必须加载C库的第二个副本以满足模块的加载要求.

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.

这意味着您的静态链接"程序仍然需要文件系统上存在libc.so.6的副本，NSS或iconv或任何模块本身，以及这些模块可能需要的其他动态库，例如ld-linux.so.2，libresolv.so.2等.当人们静态链接程序时，这通常不是他们想要的.

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.

这也意味着静态链接的程序在其地址空间中有C库的两个副本，并且它们可能会争用要使用其stdout缓冲区的用户，谁可以使用非零参数来调用sbrk，那类的东西. glibc中有很多防御性逻辑可以尝试使此工作正常进行，但从来没有保证正常工作.

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.

您可能会认为您的程序不需要担心这一点，因为它从未调用过getaddrinfo或iconv，但是语言环境支持在内部使用了iconv，这意味着任何stdio.h函数可能会触发对dlopen的调用，而您不能控制它，而用户的环境变量设置却可以.

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.

这篇关于为什么不建议静态链接glibc?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！