我遇到以下问题：我正在尝试创建程序的可移植版本，因此我将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设置为，
.因此所有库都使用相对文件路径链接
.在rpath中使用是一个糟糕的主意：
.so文件放在另一个目录中，然后从该目录运行您的应用程序。正确的方法是使用-rpath=$ORIGIN功能。见man ld.so：
$ ORIGIN（或等效的$ {ORIGIN}）将扩展到包含程序或共享库的目录。因此，可以使用以下命令编译位于somedir / app中的应用程序：
gcc -Wl,-rpath,'$ORIGIN/../lib'这样，无论somedir在目录层次结构中的什么位置，它都可以在somedir / lib中找到关联的共享对象。这有助于创建“交钥匙”应用程序，这些应用程序不需要安装到特殊目录中，而是可以解压缩到任何目录中，并且仍然可以找到它们自己的共享库。
$ORIGIN语法是有点可惜，因为它被扩展为双方的变量make和bash，所以你可能需要适当地引用它。
可能导致linux尝试在原始位置而不是相对其他位置的相对位置上查找该库
链接时，可以将库指定为-lmylib或-l:libmylib.so或-l<path>/libmylib.so。在后一种情况下，运行时链接程序<path>/libmylib.so仅在该特定路径中查找库。有关详细信息man ld，请参见，选项-l。您可能想查看您的构建系统链接器命令。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句