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

Question

我有以下问题：我正在尝试创建程序的可移植版本，因此我将 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 上也可以正常工作。

Answer 1

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

在 rpath 中使用 . 是个坏主意：

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

正确的方法是使用-rpath=$ORIGIN 功能。见man ld.so：

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

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

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

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

---

什么可能导致 linux 试图在原始位置而不是像所有其他位置一样在相对位置找到库

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