使专有的ELF二进制文件在Linux上可移植 [英] making proprietary ELF binaries portable on Linux

查看:174
本文介绍了使专有的ELF二进制文件在Linux上可移植的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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

  1. 搜索所有链接的库及其依赖项,并将它们包含在二进制文件的子目录中,并将Library-Path更改为该目录.
  2. 将库静态链接到二进制文件中,并重新链接到一个大的可执行文件(如果程序未基于校验和进行自我验证).

许可不是问题,因为我不想分发创建的可移植程序,它仅供私人使用.

感谢您的回答.

解决方案

搜索所有链接的库及其依赖项,并将它们包含在二进制文件的子目录中,然后将Library-Path更改为该目录.

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

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

将库静态重新链接到二进制文件中,成为一个大可执行文件.

在AIX以外的任何UNIX系统上都无法使用:它们都将a.outfoo.so视为 final 链接产品,无法再进行进一步的链接. /p>

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

I am searching for a way to make existing proprietary ELF-binaries, which are linked against specific versions of system libraries, portable. With portable I mean making the executable work on every system with the same processor architecture and a compatible system kernel, without necessarily having the source code of the libraries (if there is no way without having the source code, it'll be fine too).

So far I thought of two possibilities, but I don't know if they are at all possible and if yes, which to choose:

  1. Searching all linked libraries and their dependencies and include them in a subdirectory of the binary and changing the Library-Path to that directory.
  2. Relinking the libraries statically into the binary file to one big executable (if the program doesn't verify itself based on a checksum).

Licensing is no issue as I don't want to distribute the created portable programs, it's for private use only.

Thanks for your answers.

解决方案

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

This would work for most shared libraries, but will not work for libc.so.6 (which is the one most likely to give problems if your target system doesn't have new enough version).

The reason: glibc consists of over 200 separate shared libraries, which have un-versioned binary interfaces between them, and do not have a stable ABI between them. Because of this, all parts of glibc must come from the same build. One of these parts is libc.so.6. Another is ld-linux.so. An absolute path to the latter is hard coded into every dynamic executable. The end result: if you supply your own copy of libc.so.6, and if that copy doesn't match /lib/ld-linux*.so.2 present on the system, then you'll see very strange crashes which you would have very hard time to explain or debug.

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

That can't work on any UNIX system other than AIX: they all consider a.out and foo.so to be the final link product, which can't be linked any further.

There exists statifier, which does create a (huge) static executable out of a dynamic one. I have no experience using it.

这篇关于使专有的ELF二进制文件在Linux上可移植的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆