我可以在 Redhat Linux 机器上使用在 Ubuntu 上编译的共享库吗？
我在 Ubuntu 9.10 桌面上编译了一个共享库。我想将共享库发送给拥有 Red Hat Enterprise 5 盒子的合作开发人员。
他可以在他的机器上使用我的共享库吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我在 Ubuntu 9.10 桌面上编译了一个共享库。我想将共享库发送给拥有 Red Hat Enterprise 5 盒子的合作开发人员。
他可以在他的机器上使用我的共享库吗？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（5）
第一点：所有有关编译器版本的答案似乎都被误导了。重要的是联系（当然还有架构）。
如果将 .so 文件复制到启动系统（进入其自己的
/usr/local/*或/opt/*目录，例如）然后尝试使用 LD_PRELOAD 环境设置运行预期的可执行文件。如果链接器 (ld-linux.so) 设法解析两者之间的所有符号，则程序应该加载并运行。所以它应该是可能的，并且相当安全（只要你没有覆盖任何现有的系统库并且只使用 LD_*
/etc/ld.so.preload（在 chroot 中） ？）将目标可执行文件链接到这个库是一个坏主意。Ubuntu 和 Red Hat 都有很好的包管理工具。关于包管理将是 ServerFault 或 SuperUser，绝对不是这样）。
First point: all of the answers regarding compiler version seem misguided. What's important are the linkages (and the architecture, of course).
If you copy the .so file over to the start system (into its own
/usr/local/*or/opt/*directory, for example) then try to run the intended executable using an LD_PRELOAD environment settings. If the linker (ld-linux.so) manages to resolve all the symbols between the two then the program should load and run.So it should be possible, and reasonably safe (so long as you're not over-writing any of the existing system libraries and just using LD_*
/etc/ld.so.preload(in a chroot?) magic to link the target executables to this library.However, I think it's a bad idea. You have a package management issue. Both Ubuntu and Red Hat have fine package management tools. Use them! (Note the proper place to ask questions about package management would be ServerFault or SuperUser, definitely not SO).
不太可能：如果它有效的话你就不会问这个问题了，不是吗？
根据DistroWatch，Ubuntu 9.10使用
glibc-2.10.1，而 RHEL-5.4 使用 glibc-2.5。这意味着，如果您的库引用GLIBC_2.6及更高版本的任何符号，它将无法在 RHEL-5 上运行。您可以通过以下方式判断是否使用任何此类符号（以及哪些符号）：
如果输出非空，则该库将无法在 RHEL-5 上运行。
您可以使用 autopackage 构建与 RHEL-5 兼容的库。
Unlikely: you wouldn't have asked this question if it just worked, would you?
According to DistroWatch, Ubuntu 9.10 uses
glibc-2.10.1, while RHEL-5.4 usesglibc-2.5. This means that if your library references any symbols with versionsGLIBC_2.6and above, it will not work on RHEL-5.You can tell whether you use any such symbols (and which ones) with:
If the output is non-empty, then the library will not work on RHEL-5.
You might be able to build a library compatible with RHEL-5 by using autopackage.
我加入Xinus。恕我直言，对于 Ubuntu 和 RHEL，编译器将是 gcc，与 glibc 紧密耦合。因此，如果在两台机器上它是相同的，那么它很可能可以运行。
但为什么要猜测，做一个小测试驱动（主要有几行），如果它正在运行，那么一个更大的程序很有可能可以在“敌对”环境中运行:)
I join to Xinus. IMHO compiler, in case of Ubuntu and RHEL, it will be gcc, is tightly coupled with glibc. So if on both machines it's same, than most probably it caa run.
But why guessing, do a small test drive (main with couple of lines) and if it's running than there's a good chance that a bigger program can run on a "hostile" environment :)
最好的解决方案是将您的代码提供给您的合作开发人员，
让我们编译它！！！！
您有几种解决方案
您必须检查你们是否都在相同的体系结构 32 位或 64 位上工作。
我的意见是你可能会遇到一些问题，因为你可能不使用相同的 glibc 。
。
The best solution is to give your code to your co developper,
and let's compile it !!!!
You have several solution
You must check if you both work on the same architecture 32 bits or 64 bits.
My opinion is that you can have some problems , because you probably do not use the same glibc
.
是的，这是可能的。向您的合作伙伴提供静态库，并使您的 gcc 保持相同或兼容的版本。你可以在这里查看我的帖子：https://zqfan.github。 io/2021/07/01/cpp-static-library/
Yes, it is possible. Provide a static library to your partner and keep your gcc to the same or compatible version. you can check my post here: https://zqfan.github.io/2021/07/01/cpp-static-library/