代码之家 › 专栏 › 技术社区 › Shcheklein

Linux静态链接死了?

static-linking glibc gcc linux

Shcheklein · 技术社区 · 14 年前

事实上,

2.22. 即使是静态链接的程序也需要一些共享库这对我来说是不可接受的。什么我能做什么?

{AJ}NSS(有关详细信息,请键入`info libc“Name Service Switch”')不会在没有共享资源的情况下正常工作图书馆。NSS允许使用不同的服务(如NIS、文件、db、hesiod) 只需更改一个配置文件(/etc)/nsswitch.conf)没有缺点是现在是静态的图书馆需要访问共享的

一个解决方案是用仅使用服务dns和文件您需要显式链接
 gcc -static test-netdb.c -o test-netdb \
   -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group
这种方法的问题是将NSS例程用于所有那些图书馆。
正在使用NSS。没有开关不再。所以是这样 高度地 不使用系统不一致。

考虑到这个事实,现在有没有合理的方法在Linux上创建一个完整的静态构建,或者静态链接在Linux上完全死掉了?我是说静态构建:

动态构建do(静态nss) 不一致的行为是邪恶的!);
研究glibc环境和Linux版本的合理变化;

5 回复 | 直到 14 年前

Dummy00001 14 年前

考虑到这个事实,现在有没有合理的方法在Linux上创建一个完整的静态构建,或者静态链接在Linux上完全死掉了?

我不知道在哪里可以找到历史文献,但是是的, static linking 已经死在GNU系统上了(我相信它在从libc4/libc5到libc6/glibc2.x的转换过程中消亡了。)

安全漏洞。静态链接的应用程序甚至不支持libc的升级。如果应用程序是在包含lib漏洞的系统上链接的,那么它将在静态链接的可执行文件中永久存在。
du -sh /usr/lib 了解问题的严重程度。)

Ketil 14 年前

我认为这是非常烦人的,我认为称一个特性为“无用”是傲慢的,因为它在处理某些用例时有问题。glibc方法的最大问题是它硬编码到系统库(gconv以及nss)的路径,因此当人们试图在Linux发行版上运行一个静态二进制文件时,它就会中断,而Linux发行版与它的构建版本不同。

不管怎样,你可以通过设置gconv\u路径来解决gconv的问题,这样我就可以在Ubuntu上构建二进制文件并在redhat上运行它们。

nh2 5 年前

静态链接又开始上升了!

去吧编程语言可执行文件是静态链接的。
- 增加的 可移植性和向后兼容性 是他们受欢迎的原因之一。
其他编程语言也在努力使静态链接变得非常简单,例如:
- (我正在做这个 effort
- 齐格 (见 here 详细信息)
可配置 /套装套装,如 NixOS / nixpkgs 使之能够静态链接他们的包的很大一部分(例如,它的 pkgsStatic
静态链接可以产生更好的 未使用代码消除
libcs类 musl
一些大型软件各国领导人对此意见一致。例如 Google is writing new libc targeted at static linking ( “支持静态非饼图和静态饼图链接” ).

Smi 7 年前

但其他人不应该把大部分时间花在这上面。静态链接将使您远离库搅动。开发人员可以根据软件的时间表升级软件的依赖项,而不是在出现新的库版本时就被迫升级。这对于具有复杂用户界面的面向用户的应用程序非常重要,这些应用程序需要控制它们不可避免地依赖的许多较低级别库的流量。这就是为什么我总是喜欢静态链接。如果你能静态链接交叉编译的便携式C和C++代码,你就可以使世界变得更像牡蛎,因为你可以更快地将复杂的软件交付到世界上不断增长的各种设备中。

Dean Harding 14 年前

仅仅因为你必须动态链接到NSS服务并不意味着你不能一些动态链接库。并不是说静态链接“不可能”或者“不起作用”。

Community CDub 7 年前

添加其他答案:

根据斯大利的描述:

静态linux是基于手工选择的最佳工具集合客户端,如st、surf、dwm、dmenu),

它还通过避免glibc来减少二进制大小静态链接的二进制文件通常比它们的动态链接的glibc副本!!!)。注意,这差不多

由于静态链接的二进制文件启动速度更快, 发行版还以业绩增长为目标。

你可以阅读更多关于它的文章 this question about static vs dynamic linking .