Linux 静态链接已死? [英] Linux static linking is dead?
问题描述
事实上，Linux 上的 -static gcc 标志现在不起作用.让我引用 GNU libc 常见问题解答:
In fact, -static gcc flag on Linux doesn't work now. Let me cite from the GNU libc FAQ:
2.22.即使是静态链接的程序也需要一些共享库这对我来说是不可接受的.什么我可以吗?
{AJ} NSS(有关详细信息，只需键入 `infolibc "Name Service Switch"') 不会无需共享即可正常工作图书馆.NSS 允许使用不同的服务(例如 NIS、文件、db、hesiod)只需更改一种配置文件 (/etc/nsswitch.conf) 没有重新链接任何程序.唯一的缺点是现在是静态的图书馆需要访问共享图书馆.这是处理由 GNU C 库透明地提供.
{AJ} NSS (for details just type `info libc "Name Service Switch"') won't work properly without shared libraries. NSS allows using different services (e.g. NIS, files, db, hesiod) by just changing one configuration file (/etc/nsswitch.conf) without relinking any programs. The only disadvantage is that now static libraries need to access shared libraries. This is handled transparently by the GNU C library.
一个解决方案是配置glibc--enable-static-nss.在这种情况下，您可以创建一个静态二进制文件，它将仅使用服务 dns 和文件(为此更改/etc/nsswitch.conf).您需要明确链接所有这些服务.例如:
A solution is to configure glibc with --enable-static-nss. In this case you can create a static binary that will use only the services dns and files (change /etc/nsswitch.conf for this). You need to link explicitly against all these services. For example:
gcc -static test-netdb.c -o test-netdb
-Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group
这种方法的问题是你必须链接每个静态使用 NSS 例程的程序所有这些库.
{UD} 事实上，不能再说一个用这个选项编译的 libc正在使用 NSS.没有开关了.因此它高度推荐不要使用--enable-static-nss 因为这使得程序在系统不一致.
The problem with this approach is
that you've got to link every static
program that uses NSS routines with
all those libraries.
{UD} In fact, one cannot say anymore that a libc compiled with this option
is using NSS. There is no switch
anymore. Therefore it is highly
recommended not to use
--enable-static-nss since this makes the behaviour of the programs on the
system inconsistent.
关于这个事实，现在是否有任何合理的方法可以在 Linux 上创建功能齐全的静态构建，或者静态链接在 Linux 上完全失效?我的意思是静态构建:
Concerning that fact is there any reasonable way now to create a full-functioning static build on Linux or static linking is completely dead on Linux? I mean static build which:
- 行为方式与动态构建(static-nss with不一致的行为是邪恶的！);
- 适用于 glibc 环境和 Linux 版本的合理变化；
推荐答案
关于这个事实，现在有没有什么合理的方法可以在 Linux 上创建一个功能齐全的静态构建，或者静态链接在 Linux 上完全死了?
Concerning that fact is there any reasonable way now to create a full-functioning static build on Linux or static linking is completely dead on Linux?
我不知道在哪里可以找到历史参考资料，但是是的，静态链接已死在 GNU 系统上.(我相信它在从 libc4/libc5 到 libc6/glibc 2.x 的过渡过程中死了.)
I do not know where to find the historic references, but yes, static linking is dead on GNU systems. (I believe it died during the transition from libc4/libc5 to libc6/glibc 2.x.)
由于以下原因，该功能被认为无用:
The feature was deemed useless in light of:
安全漏洞.静态链接的应用程序甚至不支持升级 libc.如果应用链接到包含 lib 漏洞的系统上，那么它将在静态链接的可执行文件中永久存在.
Security vulnerabilities. Application which was statically linked doesn't even support upgrade of libc. If app was linked on system containing a lib vulnerability then it is going to be perpetuated within the statically linked executable.
代码膨胀.如果许多静态链接的应用程序在同一个系统上运行，标准库将不会被重用，因为每个应用程序都包含它自己的所有副本.(尝试 du -sh/usr/lib 以了解问题的严重程度.)
Code bloat. If many statically linked applications are ran on the same system, standard libraries wouldn't be reused, since every application contains inside its own copy of everything. (Try du -sh /usr/lib to understand the extent of the problem.)
尝试挖掘 10-15 年前的 LKML 和 glibc 邮件列表档案.我很确定很久以前我看到过一些与 LKML 相关的内容.
Try digging LKML and glibc mail list archives from 10-15 years ago. I'm pretty sure long ago I have seen something related on LKML.
这篇关于Linux 静态链接已死?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
