Joh*_*ohn 5 linux glibc binary-compatibility
确定预编译二进制文件的依赖项（特别是关于 glibc 和 libstdc++ 符号和版本）然后确保目标系统安装了这些依赖项的最佳方法是什么？
我有一个限制，我不能提供在每台机器上编译的源代码（雇主限制），所以“在每台机器上编译以确保兼容性”的实际响应是不合适的。我也不希望提供静态编译的二进制文件 -> 似乎是使用锤子打开鸡蛋的情况。
我已经考虑了许多方法，这些方法大致围绕确定我的可执行文件/库需要的符号/库通过使用诸如ldd -v </path/executable>
or
之类的命令
objdump -x </path/executable> | grep UND
，然后以某种方式在目标系统上运行命令以检查是否提供了此类符号、库和版本（不完全确定我如何执行此步骤？）。然后将跟随一些模式或符号匹配以确保存在正确的版本或更高版本。
也就是说，我觉得这已经在很大程度上为我完成了，我正在遭受......“知识差距？” 它目前是如何实施的。
关于如何进行的任何想法/建议？
我应该补充一点，这是为了在各种 linux 发行版上安装我的软件 - 特别是定制的集群 - 可能不遵守发行指南或标准化的打包方法。目标是无缝安装。
GNU 库（glibc 和 libstdc++）支持一种称为符号版本控制的机制。首先，这些库导出动态链接器使用的特殊符号来解析适当的符号版本（libstdc++ 中的 CXXABI_* 和 GLIBCXX_*，glibc 中的 GLIBC_*）。一个简单的脚本：
nm -D libc.so.6 | grep " A "
将返回版本符号列表，然后可以进一步对其进行 shell 处理，以确定支持的最大 libc 接口版本（对于 libstdc++ 也同样有效）。在 C 代码中，可以选择使用 dlvsym() 执行相同的操作（首先 dlopen() 库，然后检查是否可以使用 dlvsym() 查找所需符号的某些最小版本）。
在运行时获取 glibc 版本的其他选项包括 gnu_get_libc_version() 和 confstr() 库调用。
然而，版本控制接口的正确使用是编写显式链接到特定 glibc/libstdc++ 库版本的代码。例如，链接到 GLIBC_2.10 接口版本的代码预计适用于任何高于 2.10 的 glibc 版本（2.18 及更高版本的所有版本）。虽然可以在每个符号的基础上启用版本控制（使用“.symver”汇编器/链接器指令），但更合理的方法是使用工具链的旧版本（支持的最低版本）设置 chroot 环境，并根据该版本编译项目它（它将与遇到的任何新版本无缝运行）。