Linux LD#u PRELOAD='/something/$LIB/libmyx.so'；我的计划在不同的条件下扩展？

我在查找正确的库时遇到错误

ERROR: ld.so: object '/ws/sarvi-sjc/cel8root/$LIB/libwisktrack.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

我的库的设置如下

bash-4.4$ ls -alR /ws/sarvi-sjc/cel8root/
/ws/sarvi-sjc/cel8root/:
total 36
drwxr-xr-x.  6 sarvi eng  4096 Sep 23 22:46 .
drwxr-xr-x. 88 sarvi eng 16384 Sep 23 22:12 ..
drwxr-xr-x.  2 sarvi eng  4096 Sep 23 22:56 lib
drwxr-xr-x.  2 sarvi eng  4096 Sep 23 22:56 lib32
drwxr-xr-x.  2 sarvi eng  4096 Sep 23 22:56 lib64

/ws/sarvi-sjc/cel8root/lib:
total 29452
drwxr-xr-x. 2 sarvi eng     4096 Sep 23 22:56 .
drwxr-xr-x. 6 sarvi eng     4096 Sep 23 22:46 ..
-rwxrwxrwx. 1 sarvi eng 30024352 Sep 23 22:38 libwisktrack.so

/ws/sarvi-sjc/cel8root/lib32:
total 29428
drwxr-xr-x. 2 sarvi eng     4096 Sep 23 22:56 .
drwxr-xr-x. 6 sarvi eng     4096 Sep 23 22:46 ..
-rwxrwxrwx. 1 sarvi eng 30003020 Sep 23 22:56 libwisktrack.so

/ws/sarvi-sjc/cel8root/lib64:
total 28792
drwxr-xr-x. 2 sarvi eng     4096 Sep 23 22:56 .
drwxr-xr-x. 6 sarvi eng     4096 Sep 23 22:46 ..
-rwxrwxrwx. 1 sarvi eng 29349680 Sep 23 22:56 libwisktrack.so
bash-4.4$ 
bash-4.4$ file /ws/sarvi-sjc/cel8root/lib/libwisktrack.so 
/ws/sarvi-sjc/cel8root/lib/libwisktrack.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=c38570777cfc99005a4693f68adf1014b7d647fd, with debug_info, not stripped, too many notes (256)
bash-4.4$ file /ws/sarvi-sjc/cel8root/lib32/libwisktrack.so 
/ws/sarvi-sjc/cel8root/lib32/libwisktrack.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=be90026de8fad17a99582991f1983e321a17ea87, with debug_info, not stripped, too many notes (256)
bash-4.4$ file /ws/sarvi-sjc/cel8root/lib64/libwisktrack.so 
/ws/sarvi-sjc/cel8root/lib64/libwisktrack.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=223ca6c07b59b940355a3ca8299df8f68743c22a, with debug_info, not stripped, too many notes (256)
bash-4.4$ 

据我所知，32位和64位版本的libwisktrack.so的库安装是正确的

当我编译自己的testprog32和testprog64时，它们似乎正确地加载了各自的库

bash-4.4$ file tests/testprog32 
tests/testprog32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a9db0c61d648adf715a79c5cfb7b06f6a128b90e, not stripped
bash-4.4$ LD_PRELOAD='/ws/sarvi-sjc/cel8root/$LIB/libwisktrack.so' tests/testprog32
Constructor: 92729
testprog running......
Command: takes one argument. Which system call to run
Options: readlink, vprintf, printf, open, fopen, creat

bash-4.4$ file tests/testprog64
tests/testprog64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=fbb14df720b2997c56995c98b2ad28734f554bb9, not stripped
bash-4.4$ LD_PRELOAD='/ws/sarvi-sjc/cel8root/$LIB/libwisktrack.so' tests/testprog64
Constructor: 92349
testprog running......
Command: takes one argument. Which system call to run
Options: readlink, vprintf, printf, open, fopen, creat

然而，这个程序很难找到正确的库，而且似乎选择了错误的库

bash-4.4$ file /nobackup/sarvi/xrwisktest/binos/linkfarm/host/sdk/sysroots/x86_64-xesdk-linux/usr/bin/protoc
/nobackup/sarvi/xrwisktest/binos/linkfarm/host/sdk/sysroots/x86_64-xesdk-linux/usr/bin/protoc: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /nobackup/sarvi/xrwisktest/binos/linkfarm/host/sdk/sysroots/x86_64-xesdk-linux/lib/ld-linux-x86-64.so.2, BuildID[sha1]=f52e087673df429ad5849877b08d89b080e934c2, for GNU/Linux 2.6.32, stripped
bash-4.4$ 

bash-4.4$ LD_PRELOAD='/ws/sarvi-sjc/cel8root/$LIB/libwisktrack.so' /nobackup/sarvi/xrwisktest/binos/linkfarm/host/sdk/sysroots/x86_64-xesdk-linux/usr/bin/protoc
ERROR: ld.so: object '/ws/sarvi-sjc/cel8root/$LIB/libwisktrack.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Usage: /nobackup/sarvi/xrwisktest/binos/linkfarm/host/sdk/sysroots/x86_64-xesdk-linux/usr/bin/protoc [OPTION] PROTO_FILES

我错过了什么

我注意到64位testprog64和失败的64位程序之间的一个区别是

interpreter /lib64/ld-linux-x86-64.so.2
Vs 
interpreter /nobackup/sarvi/xrwisktest/binos/linkfarm/host/sdk/sysroots/x86_64-xesdk-linux/lib/ld-linux-x86-64.so.2

不知道这有什么关系

更新： strace显示它打开以下文件进行64位程序调用，这对我来说没有意义

open("/ws/sarvi-sjc/wisktrack/cel8root/lib/libwisktrack.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

这不应该打开lib64或lib/x86_64或lib/x86_64-linux-gnu路径之一吗

为了明确起见，我不想使用LD_LIBRRY_PATH，因为我遇到了一些程序/脚本明确禁止设置LD_LIBRARY_PATH的用例，例如我在SDK中找到的“python setup.py install”

因此，我希望不必使用LD_LIBRARY_PATH就可以完成这项工作。“$LIB”持续工作是我知道的唯一选择

---

Mine是RHEL8开发主机。从为主机编译的SDK中提取的特定程序遇到问题，用于构建其他交叉编译程序，作为大型构建系统的一部分。

在Debian系统上，我创建了一个迷你

。因此，

使用（（构造函数））例程
写入消息并用此设置确认.ctor输出：

64位库：

$HOME/lib/x86\u 64-linux-gnu/ctor.so

LD_PRELOAD='$LIB/ctor.so'/bin/echo

这个问题的答案更长 提供32位与64位的详细信息

---

以及运行时链接器对不同发行版的不同子目录的使用。

$LIB

来自

ld的文档。因此

man:

这并非完全正确，实际值可能不同。例如，您正在从OpenEmbedded SDK运行nativesdk二进制文件。正如您所注意到的，SDK使用自己的

ld.so

。该

ld.so

未配置为支持多库，它希望只有一个带有64位库的

lib

目录。这就是为什么它将

$LIB

解析为

LIB

您可以在此处看到默认库目录定义（

BASELIB

）：

---

正如我所解释的那样。strace显示它正在寻找“open”（/ws/sarvi sjc/wisktrack/cel8root/lib/libwisktrack.so），O|RDONLY | O|u CLOEXEC）=-1 enoint（没有这样的文件或目录）open（/ws/sarvi sjc/wisktrack/cel8root/lib/libwisktrack.so），O|RDONLY | O|CLOEXEC）=-1 enoint（没有这样的文件或目录）``在64位机器上，上面的例子使用了一个相对路径；链接帖子中的相关内容建议使用相对路径名而不是绝对路径名设置LD_PRELOAD；也可以提供LD_库_路径；可能需要根据

strace

的新结果调整细分曲面。您的Linux发行版和版本是什么？构建主机是RHEL8，对于32位ann，ld.so似乎将$LIB映射到LIB，对于64位ann.lib64。用于为主机生成的二进制文件。但是构建系统也使用了一个SDK，该SDK是yocto/open嵌入式的。提取的sdk中的可执行文件似乎在使用自己的ld。因此，在同一个64位主机上，$LIB似乎映射到LIB。因此，除非我查找要运行的可执行文件并知道它将使用哪个ld.So，无论是从主机还是从构建系统内的SDK，否则我无法确定$LIB将映射到哪个

   $LIB (or equivalently ${LIB})
          This expands to lib or lib64 depending on the architecture
          (e.g., on x86-64, it expands to lib64 and on x86-32, it
          expands to lib).