我遇到过这样的情况：一组开发人员试图将一个二进制应用程序部署到一系列 RHEL 5.5 和 CentOS 5.5 服务器。不幸的是，该应用程序是在另一个平台（Gentoo）上开发的，执行时出现 GLIBC 依赖性错误：
libc.so.6: version `GLIBC_2.7' not found (required by
/path/to/application/bin/program.app)
RHEL/CentOS 5.x 在 GLIBC 2.5 上实现标准化（带有补丁和反向移植，但仍停留在 2.5）
我能够通过复制单个库并LD_PRELOAD在包装器脚本中使用来解决其他库要求。我的立场是，RHEL 旨在在整个支持生命周期内保持二进制兼容性，并且我没有任何好的选项来升级系统上如此重要的库。环境以前主要是 Gentoo，因此开发人员习惯于能够逐个升级软件包而不会出现任何真正的依赖性问题。
我认为正确的解决方案是针对目标系统重新编译。由于应用程序分发方法，这可能不是一个选项。还有其他解决方案或建议吗？
答案1
- 静态链接（-static）
- 使用 rpath。rpath 覆盖默认搜索路径（-rpath，/srv/myapp/lib）