Linux 发行版之间的二进制兼容性
抱歉，如果这是一个显而易见的问题，但我在网络上发现的参考资料出人意料地少......
我正在使用由我们的业务合作伙伴之一用 C 编写的 API，并以 .so 二进制文件的形式提供给我们，构建在 Fedora 11 上。我们一直在 Fedora 11 开发机器上测试 API，没有出现任何问题。但是，当我尝试链接客户的目标平台（恰好是 SuSE Enterprise 10.2）上的 API 时，我收到“文件格式无法识别”错误。
同样属于 binutils 软件包一部分的命令（例如 objdump 或 nm）也会出现相同的文件格式错误。 “file”命令显示：
ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
而“ldd”命令显示：
ldd: warning: you do not have execution permission for `./libuscuavactivity.so.1.1'
./libuscuavactivity.so.1.1: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./libuscuavactivity.so.1.1)
[dependent library list]
我猜测这是由于两个平台上的 C 库之间不兼容造成的，问题在于代码是针对新版本的 glibc 等进行编译的比 SuSE 10.2 上可用的版本。我发布这个问题的原因是，有一种方法可以在我们合作伙伴的 Fedora 11 平台上编译代码，使其也可以在 SuSE 10.2 上运行。
Sorry if this is an obvious question, but I've found surprisingly few references on the web ...
I'm working with an API written in C by one of our business partners and supplied to us as a .so binary file, built on Fedora 11. We've been testing out the API on a Fedora 11 development machine with no problems. However, when I try to link against the API on our customer's target platform, which happens to be SuSE Enterprise 10.2, I get a "File format not recognized" error.
Commands that are also part of the binutils package, such as objdump or nm, give me the same file format error. The "file" command shows me:
ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
and the "ldd" command shows:
ldd: warning: you do not have execution permission for `./libuscuavactivity.so.1.1'
./libuscuavactivity.so.1.1: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./libuscuavactivity.so.1.1)
[dependent library list]
I'm guessing this is due to incompatibility between the C libraries on the two platforms, with the problem being that the code was compiled against a new version of glibc etc. than the one available on SuSE 10.2. I'm posting this question on the off chance that there is a way to compile the code on our partner's Fedora 11 platform in such a way that it will run on SuSE 10.2 as well.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我认为诀窍是使用您希望支持的任何平台的最旧的内核和 C 库版本构建 Linux 风格。在我的工作中，我们基于 Debian 4 进行构建，这使我们能够以非官方的方式正式支持 Debian 4 及更高版本、RedHat 3、4、5、SuSE 10 以及各种其他发行版（SELinux 等）。
我怀疑，通过在 Linux 的新版本上进行构建，支持旧机器上的用户会变得很困难。
（编辑）我应该提到我们使用 Debian 4 附带的默认编译器，我认为是 GCC 4.1.2。安装较新的编译器版本往往会使兼容性变得更差。
I think the trick is to build on a flavour of linux with the oldest kernel and C library versions of any of the platforms you wish to support. In my job we build on Debian 4, which allows us to officially support Debian 4 and above, RedHat 3,4,5, SuSE 10 plus various other distros (SELinux etc.) in an unofficial fashion.
I suspect by building on a nice new version of linux, it becomes difficult to support people on older machines.
(edit) I should mention that we use the default compiler that comes with Debian 4, which I think is GCC 4.1.2. Installing newer compiler versions tends to make compatibility much worse.
Windows 在不同版本、服务包、已安装的 SDK 和一般 DLL 之间存在兼容性问题（DLL Hell，有人吗？）。 Linux 也不能免受同类问题的影响。
我看到的兼容性问题包括：
在您的特定情况下，我会让他们在其系统上执行“gcc -v”并向您报告 gcc 版本号。将其与您正在使用的进行比较。
您可能需要获取该版本的编译器来构建您的一半。
Windows has it problems with compatability between different realeases, service packs, installed SDKs, and DLLs in general (DLL Hell, anyone?). Linux is not immune to the same kinds of issues.
The compatability issues I have seen include:
In your particular case, I'd have them do a "gcc -v" on their system and report to you the gcc version number. Compare that to what you are using.
You might have to get hold of that version of the compiler to build your half with.
您可以使用Linux应用程序检查器工具（[ 1]、[2]、[3]），以解决 Linux 发行版之间应用程序的兼容性问题。它将检查您的文件格式和所有依赖库。它支持几乎所有流行的 Linux 发行版，包括 SuSE 和 Fedora 的所有版本。
You can use Linux Application Checker tool ([1], [2], [3]) in order to solve compatibility problems of an application between Linux distributions. It will check your file formats and all dependent libraries. It supports almost all popular Linux distributions including all versions of SuSE and Fedora.
这只是个人意见，但是在 Linux 上以纯二进制形式分发某些内容时，您有几个选择：
为每个发行版构建 .debs 和 .rpms 的范围，并使用名义上的“.tar” .gz 充满二进制文件”包，用于查找您错过的任何内容。第一部分很理想但很麻烦。后一部分将引导您到第 2 点和第 3 点。
按照某些人的建议进行操作，找到您可以找到并在那里构建的最旧的发行版。我个人认为这是一个荒谬的想法。请参阅第 3 点。
分发二进制文件，并尽可能静态链接。特别是对于 libstdc++，这似乎是您的问题。似乎存在很多不兼容的 libstdc++ 版本，这使其成为兼容性噩梦。如果无法静态链接，您还可以将 *.so 文件与二进制文件放在一起，并使用
LD_PRELOAD或LD_LIBRARY_PATH等内容使它们在运行时优先链接。请注意，如果您采取这种方式，您可能必须遵守 LGPL 等，因为您现在正在将其他人的工作与您的项目一起分发。当然，在 Linux 上以源代码形式分发项目始终是首选。 :-)
This is just a personal opinion, but when distributing something in binary-only form on Linux, you have a few options:
Build the gamut of .debs and .rpms for every distro under the sun, with a nominal ".tar.gz full of binaries" package for anything you've missed. The first part is ideal but cumbersome. The latter part will lead you to point 2 and 3.
Do as some are suggesting and find the oldest distro you can find and build there. My own opinion is this is sort of a ridiculous idea. See point 3.
Distribute binaries, and statically link where ever you can. Especially for libstdc++, which appears to be your problem here. There are seemingly very many incompatible versions of libstdc++ floating around, which makes it a compatibility nightmare. If you can't link statically, you can also put *.so files alongside your binary, and use stuff like
LD_PRELOADorLD_LIBRARY_PATHto make them link preferentially at runtime. Note that if you take this route you may have to comply with LGPL etc. since you are now distributing other people's work alongside your project.Of course, distributing your project in source form is always preferred on Linux. :-)
如果消息是无法识别的文件格式，那么问题很可能是 elmarco 在评论中提到的问题——即不同的体系结构。它可能（我不确定）是动态链接器版本不匹配，但这意味着 .so 文件是使用古老的动态链接器构建的。我不相信 libc 中的任何不兼容性会导致这种情况——它们可能会导致链接失败和运行时问题（后者很少见），但不是这个。
If the message is file format not recognized then the problem is most likely one mentioned by elmarco in a comment -- namely, different architecture. It might (I'm not sure) be a dynamic linker version mismatch, but that would mean the .so file was built with an ancient dynamic linker. I do not believe any incompatibility in libc could cause this -- they could cause link failures and runtime problems (latter very rarely), but not this.
我不了解 Suse，但我知道 fedora 喜欢走在最前沿。所以你对库版本的看法很可能是正确的。为什么不询问并看看是否可以获得源代码并在您的 Suse 计算机上构建它？
I don't know about Suse, but I know fedora likes to stay on the bleeding edge. So you may very well be right about library versions. Why don't you ask and see if you can get the source code and build it on your Suse machine?