分发静态链接的 ELF 32 位二进制文件 - 它可以在所有平台上运行吗？
我的团队已准备好发布 Linux 程序的第一个版本，并希望以最简单的方式（对于用户）来发布。
该程序不需要外部文件，无需安装，并且是静态链接的。
ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.15, not stripped
我的问题是这样的二进制文件是否可以在大多数 Linux 平台（Ubuntu、Redhat、OpenSuse 等）上运行？
我还有点担心“for GNU/Linux 2.6.15”的部分，这是否意味着它们需要内核 2.6.15 或更高版本？
My team is ready to release the first version of our Linux program and would like to do so in the easiest possible manner (for users).
The program needs no external files, no install, and is statically linked.
ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.15, not stripped
My question is whether such a binary will run on most Linux platforms (Ubuntu, Redhat, OpenSuse, etc)?
I'm also a bit concerned about the part where it says 'for GNU/Linux 2.6.15', does this mean that they need kernel 2.6.15 or higher?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不再推荐完全静态链接的程序。
可移植层从内核调用移至基本库（还记得 pthread 灾难和 LinuxThreads <-> NPTL 线程的问题吗？）。
遵循LSB 4.0标准。相信那里提到的库的存在（不幸的是没有那么多）并将所有其他共享库与您的应用程序捆绑在一起。有一个链接器标志 - 我认为它是 -L - 您可以在其中设置一个 ldd 路径，该路径在共享库加载期间优先于所有其他设置，因此您的库始终首先加载。
确保所有库仅调用 LSB 批准的 API 函数（或者查看 LSB 网站，了解不受支持的 LSB API 调用有多严重 - 有时您根本无法避免它，并且他们有支持此功能的发行版列表称呼）。
这是提供二进制可执行文件的推荐方法。与 Windows/MacOSX 相比，它在 Linux 上仍然很糟糕。
Full statically linked programs are not recommended anymore.
The portability layer moved from kernel calls into the basic libraries (remember the pthread desaster and the problems with LinuxThreads <-> NPTL threads?).
Follow the LSB 4.0 standard. Trust in the existence of the libraries mentioned there (not so many unfortunately) and bundle all the other shared libraries with your application. There is a linker flag - i think it was -L - where you can set a ldd path which has precedence over all other settings during shared library loading so your libs are always loaded first.
Make sure that all libraries only call LSB approved API functions (or have a look on the LSB website and see how serious a non supported LSB API call is - sometimes you simply can't avoid it and they have a list of Distributions that support this call).
This is the recommended way to deliver binary executables. And it still sucks a lot on Linux compared to Windows/MacOSX.