Linux C++ 尝试使用绝对路径加载一个特定库，而所有其他库则使用相对路径链接

我有以下问题：我正在尝试创建程序的可移植版本，因此我将 rpath 设置为“。”因此所有库都使用相对文件路径链接。这确实适用于除一个库之外的所有库。由于某种原因，只有当一个特定库存在于编译时链接的同一位置时，该程序才能工作。这是我自己写的，它的rpath也设置为“.”。因此基本上，即使库与可执行文件位于完全相同的位置，程序也将拒绝启动。
我已经验证只有一个库有问题，因为如果我在测试计算机上创建我的计算机上的库所在的文件夹，程序就会启动。

linux-vdso.so.1 =>  (0x00007ffcc5961000)
libOgreHlmsPbs.so.2.1.0 => ./libOgreHlmsPbs.so.2.1.0 (0x00007fedeec3f000)
libOgreHlmsUnlit.so.2.1.0 => ./libOgreHlmsUnlit.so.2.1.0 (0x00007fedeea1d000)
libOgreMain.so.2.1.0 => ./libOgreMain.so.2.1.0 (0x00007fedee194000)
/home/marvin/workspace/HLMS_DS_DEMO/libHLMS_DS.so => not found

那么，有谁知道什么可能导致 linux 尝试在原始位置而不是像其他所有位置一样在相对位置查找该库？该程序在 Windows 上也运行良好。

我将 rpath 设置为.因此所有库都使用相对文件路径链接

Using .在 rpath 中是一个糟糕的主意：

• 可用性：应用程序必须从特定的工作目录运行。
• 安全性：攻击者可能会修改.so文件放在另一个目录中并从那里运行您的应用程序。

正确的方法是使用-rpath=$ORIGIN特征。看man ld.so:

$ORIGIN（或等效的${ORIGIN}） 这将扩展到包含程序或共享对象的目录。因此，位于 somedir/app 中的应用程序可以编译为

gcc -Wl,-rpath,'$ORIGIN/../lib'

这样无论 somedir 位于目录层次结构中的哪个位置，它都会在 somedir/lib 中找到关联的共享对象。这有助于创建“交钥匙”应用程序，这些应用程序不需要安装到特殊目录中，而是可以解压到任何目录中，并且仍然可以找到它们自己的共享对象。

$ORIGIN语法有点不幸，因为它被两者扩展为变量make and bash，因此您可能需要适当地引用它。

什么可能导致 linux 尝试在原始位置而不是像所有其他位置一样在相关位置查找该库

链接时，库可以指定为-lmylib or -l:libmylib.so or -l<path>/libmylib.so。在后一种情况下，运行时链接器在该特定路径中查找库<path>/libmylib.so仅有的。看man ld， 选项-l了解完整详情。您可能想检查您的构建系统链接器命令。