linux - 使专有的 ELF 二进制文件在 Linux 上可移植

标签 linux shared-libraries portability elf portable-applications

我正在寻找一种方法来制作现有的专有 ELF 二进制文件,这些二进制文件链接到特定版本的系统库,可移植。对于可移植性,我的意思是使可执行文件在具有相同处理器架构和兼容系统内核的每个系统上工作,而不必拥有库的源代码(如果没有源代码就没有办法,那也没关系) .

到目前为止我想到了两种可能性,但我不知道它们是否完全可能,如果是,该选择哪种:

  1. 搜索所有链接库及其依赖项,并将它们包含在二进制文件的子目录中,并将库路径更改为该目录。
  2. 将库静态地重新链接到二进制文件到一个大的可执行文件(如果程序不根据校验和验证自身)。

许可不是问题,因为我不想分发创建的可移植程序,它仅供私有(private)使用。

感谢您的回答。

最佳答案

Searching all linked libraries and their dependencies and include them in a subdirectory of the binary and changing the Library-Path to that directory.

这适用于大多数共享库,但不适用于 libc.so.6(如果您的目标系统没有足够新的版本,这是最有可能出现问题的库) .

原因:glibc 由 200 多个独立的共享库组成,它们之间具有未版本化的二进制接口(interface),并且它们之间没有稳定的 ABI。因此,glibc 的所有部分必须来自同一个构建。其中一个部分是 libc.so.6。另一个是 ld-linux.so。后者的绝对路径被硬编码到每个动态可执行文件中。最终结果:如果您提供自己的 libc.so.6 副本,并且该副本与 /lib/ld-linux*.so.2 不匹配出现在系统上,然后你会看到非常奇怪的崩溃,你将很难解释或调试。

Relinking the libraries statically into the binary file to one big executable.

这在 AIX 以外的任何 UNIX 系统上都行不通:它们都认为 a.outfoo.sofinal 链接产品,无法进一步链接。

存在statifier ,它确实从动态可执行文件中创建了一个(巨大的)静态可执行文件。我没有使用它的经验。

关于linux - 使专有的 ELF 二进制文件在 Linux 上可移植,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15386027/

相关文章:

c - 为什么父进程死亡会杀死子进程

Linux Red Hat 5.6 和 VNC : KDE & Gnome

linux - wine(linux)下运行的windows应用截图

linker - 链接共享库时限制符号的可见性

安卓NDK : C++ runtime restrictions when using prebuilt shared libraries

c++ - 仅当 CMake 中的 header 更改时才重新链接共享库

c - C99 标准是否保证 unsigned int 的二进制表示?

c++ - 访问类的 std::string 时崩溃

windows - 在 Perl 脚本中播放声音

c++ - 我可以依赖一个新的 bool 被初始化为 false 吗?