除了一些使用g ++之外,如何静态链接所有库？

Question

我要求我静态链接所有库,包括libstdc ++,libc,pthread等.有一个我想要动态链接的omniorb库.

目前我已动态链接所有库.ldd显示以下内容

linux-vdso.so.1 =>  (0x00007fff251ff000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f291cc47000)
libomniDynamic4.so.1 (0x00007f291c842000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f291c536000)
libm.so.6 => /lib64/libm.so.6 (0x00007f291c2e0000)
libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x00007f291c0d7000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f291bebf000)
libc.so.6 => /lib64/libc.so.6 (0x00007f291bb66000)
/lib64/ld-linux-x86-64.so.2 (0x00007f291ce63000)
librt.so.1 => /lib64/librt.so.1 (0x00007f291b95d000)
libomniORB4.so.1 (0x00007f291b6aa000)
libomnithread.so.3 (0x00007f291cf35000

我需要ldd将libomniDynamic4.so.1显示为唯一的动态链接库.

我该如何实现这一目标？

Answer 1

试图制作一个在所有发行版上运行的linux可执行文件呃？祝你好运......但我离题了......

你想看看-vg ++ 的标志输出.它显示了由g ++/ld执行的内部链接命令.具体来说,您需要检查最终的链接命令collect2及其所有参数.然后,您可以指定要链接的.a库的确切路径.您还必须跟踪所有内容的静态库.我的libstdc ++.a在/usr/lib/gcc/x86_64-linux-gnu/4.4/libstdc++.a

咆哮:我对linux的最大抱怨是可执行文件的破碎状态.为什么我不能在一台机器上编译二进制文件并将其复制到另一台机器上并运行它!由于libc/libstdc ++ ABI incompatibilites,即使Ubuntu发行版中的一个版本也将生成无法在另一个上运行的二进制文件

编辑#1 我只是想补充一点,这个页面上的脚本会产生一个.png的可执行文件.so依赖项.这在尝试执行您描述的操作时非常有用.

请注意,ldd <exename>将列出链中的所有依赖项,而不仅仅是可执行文件的直接依赖项.所以,即使你的可执行文件只依赖于omniorb.so,但omniorb.so依赖于libphread.so,ldd输出会列出那个.查找联机帮助页readelf以仅查找二进制文件的直接依赖项.

另外一个要注意的项目.如果omniorb.so依赖于libstdc ++.那么,你将别无选择,只能依赖于同一个lib.否则,ABI不兼容性将破坏您的代码和omniorb代码之间的RTTI.

Answer 2

我需要ldd将libomniDynamic4.so.1显示为唯一的动态链接库.

那是不可能的.

首先,ldd将始终显示需要动态链接的ld-linux-x86-64.so.2any(x86_64)二进制文件.如果您使用动态链接(您可以使用libomniDynamic4.so.1),那么您将获得ld-linux-x86-64.so.2.

其次,linux-vdso.so.1由内核"注入"你的进程.你也无法摆脱它.

接下来的问题是,为什么你要尽量少用动态库.最常见的原因通常是错误地认为"大多数静态"二进制文件更具可移植性,并且可以在更多系统上运行.在Linux上,这与真实相反.

如果实际上您正在尝试实现可移植二进制文件,则存在多种方法.到目前为止(根据我的经验)最好的一个是使用apgcc.

Answer 3

链接时，在指定要静态链接的库之前使用 -static，在要动态链接的库之前使用 -dynamic。您最终应该得到如下所示的命令行：

g++ <other options here> -dynamic -lomniDynamic4 -static -lpthread -lm -lgomp <etc>

当然，您需要要静态链接的库的 .a 版本（废话）。