根据 $LD_LIBRARY_PATH 和架构选择库答案

【问题标题】：Library choice according to $LD_LIBRARY_PATH and architecture根据 $LD_LIBRARY_PATH 和架构选择库
【发布时间】：2014-09-22 12:33:33
【问题描述】：

为了演示，我用 2 个版本的 libgcc_s.so.1 创建了 2 个文件夹我根据ldd寻找图书馆选择：

> file {A,B}/libgcc_s.so.1
A/libgcc_s.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
B/libgcc_s.so.1: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped

> LD_LIBRARY_PATH=A:B ldd MyProgram | grep libgcc_s.so.1
libgcc_s.so.1 => B/libgcc_s.so.1

为什么 MyProgram 不使用 A/libgcc_s.so.1 ？我知道这是架构问题，但 A/libgcc_s.so.1 如何被视为无效以及如何手动测试它？

【问题讨论】：

标签： linux architecture ldd

【解决方案1】：

ELF header's 第三个字段是“machine”，对于 amd64 (x86_64) 的值为 62，对于 i386 (80386) 的值为 3。加载器当然会检查这个字段以确定它是否可以使用给定的库，如果不能，它将继续到其搜索列表中的下一个路径。

【讨论】：

好的，但是我如何确定一个库是否符合当前架构？我可以获得 ELF 的第 18-19 个字节，但我不知道如何确定此代码是否符合我的实际架构。做 [[ $(readelf -h | grep $(Machine:)) == *$(uname -i)* ]] 是安全的吗？
你试图在更高层次上实现的实际目标是什么？
我有跨不同平台的共享文件夹，其中包含用于不同架构的不同库。我的实际 LD_LIBRARY_PATH 包括所有这些。我想根据架构只使用有用的文件夹来减少它，而不使用任何命名约定。
那么我认为你应该将文件夹命名为与uname -m 的输出相同的名称（例如 x86_64）。
那么确定，扫描 readelf 或 file(1) 或其他任何东西的输出并进行字符串匹配。似乎比命名约定更糟糕，但这只是我的意见。