使用 libc.so.6 捆绑 c++ 应用程序答案

【问题标题】：Bundle c++ application using libc.so.6使用 libc.so.6 捆绑 c++ 应用程序
【发布时间】：2018-03-14 13:31:15
【问题描述】：

我正在尝试使我的可执行文件在 linux 上可移植，为此我需要复制程序本身使用的所有共享库，以检查我需要使用哪一个：

ldd program_name

程序的输出帮助我找到所有需要的.so，在这些库之间有：

libc.so.6 => /lib64/libc.so.6 (0x00007f5b61ac2000)

此时我将所有库复制到一个名为shared_libs 的文件夹中，并将它们与程序一起发送到另一台电脑上，当我这样做时出现了问题：

LD_LIBRARY_PATH=./shared_libs ./program_name

给出：

[1]    4619 segmentation fault (core dumped)  LD_LIBRARY_PATH=./shared_libs ./program_name

我很确定 libc.so.6 会导致问题，因为如果我这样做：

LD_LIBRARY_PATH=./shared_libs ls

只有 shared_libs 文件夹中的那个库，ls 也会出现 seg 错误。

如何捆绑我的应用程序？

编辑 1：为什么我不静态链接所有内容？

试过了，就是头疼……

【问题讨论】：

为什么不静态链接所有的库？
使用调试器。
无论是静态链接 glibc 还是将 glibc 的一部分复制到目标平台都不是解决可移植性问题的有效解决方案。不要那样做。动态链接，不要复制glibc的部分内容（可以复制其他库），出现的任何问题都根据具体情况解决。
@S.M.在 ls?或者也许在 ld.so 上？
@n.m.我无法解决程序运送到的每台电脑的问题

【解决方案1】：

为此，我需要复制程序本身使用的所有共享库

不，你不。特别是，复制 GLIBC 根本行不通（正如您所发现的）。

您实际上需要的是针对足够旧的（不比您将程序分发到的任何系统新的）libc 构建您的程序，然后依赖 GLIBC ABI 兼容性（这保证程序当在运行时绑定到较新的 GLIBC 时，链接到旧 GLIBC 的链接会继续正确运行。

这可以通过在旧系统上构建您的程序，或使用chroot，或构建“linux to old linux”交叉编译器来实现。

我很确定是 libc.so.6 引起了问题

正确。解释了这不起作用的原因，例如here.

问题在于 GLIBC 由多个必须匹配的二进制文件组成。并且这些二进制文件之一的路径（ld-linux）在静态链接时被硬编码到程序中，并且无法更改。

【讨论】：