c - 我可以强制动态库链接到特定的动态库依赖项吗？

Question

我正在构建一个动态库libfoo.so，它依赖于libcrypto.so。

在我的自动工具Makefile.am文件中，我有这样一行:

libfoo_la_LIBADD += -L${OPENSSL_DIR}/lib -lcrypto

其中 $OPENSSL_DIR默认为 /usr，但可以通过传递 --with-openssl-dir=/whatever覆盖。

如何确保使用 libfoo.so的可执行文件仅使用 ${OPENSSL_DIR}/lib/libcrypto.so而无需构建或运行该可执行文件的人必须使用 rpath或使用 LD_LIBRARY_PATH摆弄小提琴？

就目前情况而言，我可以构建 libfoo并传递 --with-openssl-dir=/usr/local/openssl-special，它可以正常运行。但是，当我运行 ldd libfoo.so时，它只是指向 libcrypto.so中的 /usr/lib。

我能想到的唯一解决方案是将 libcrypto.a静态链接到 libfoo.so。还有其他可能的方法吗？

Answer 1

运行时动态链接的详细信息因平台而异。自动工具可以在某种程度上使您与之隔离，但是如果您关心细节(显然是您这样做的)，则可能不足以让自动工具为您选择。

话虽如此，您似乎几乎排除了所有可能性:

确保在运行时获得在构建时链接的特定实现的最可靠方法是静态链接。但是你说你不想那样。

如果改为使用动态库，则在运行时依靠动态链接器将库实现与可执行文件相关联。在这种情况下，对于如何将DL定向到特定的库实现，有两种常规选择:

通过存储在程序/库二进制文件中的信息。您正在使用建议基于ELF的系统的术语，对于ELF共享对象，是RPATH和/或RUNPATH传达有关在哪里寻找所需库的信息。没有与单个库要求相关的路径信息；它们仅由SONAME标识。但是您说您不想使用RPATH *，因此我想也不要使用RUNPATH。

通过动态链接器的静态或动态配置。这是LD_LIBRARY_PATH出现的地方，但是您说您不想使用它。动态链接程序通常还具有一个或多个配置文件，例如/etc/ld.so.conf。您可以在此处指定要搜索的库目录，并稍加注意，以搜索它们的顺序。

然后，可以通过更新动态链接程序的配置文件以使其首先搜索所需的路径，来使所需的库实现链接到应用程序。但是，这会影响整个系统，而且很脆弱。

或者，根据依赖项性质的详细信息，您可以为所需的libcrypto版本提供一个独特的SONAME。实际上，就静态和动态链接器而言，这将使其成为不同的对象(例如libdjcrypto)。但这是有风险的，因为如果您的库对libcrypto具有直接和间接的依赖关系，或者如果使用您的库的程序通过另一路径依赖于libcrypto，那么您将在运行时(动态地)链接两个库，并且可能甚至使用两个函数，具体取决于每个调用的来源。

请注意，如果您也静态链接库，则上述问题也应该引起您的注意。如果这在您的库中对 libcrypto留下了任何间接动态依赖关系，或者在使用该库的程序中来自其他源的任何动态依赖关系，那么您最终将同时使用多个版本的libcrypto。

底线

对于可执行文件，最佳选择是(1)全静态链接或(2)(对于ELF) RPATH / LD_LIBRARY_PATH / RUNPATH，以确保所有组件都通过相同的 SONAME要求目标库。我倾向于提供一个设置 LD_LIBRARY_PATH的包装器脚本，以使其作用范围狭窄。

对于可重用的库，“不要这样做”可能是最好的选择。使用另一个库的两个不同版本(在本例中为libcrypto)同时结束程序的可能性很高，这使得所有可用选项都没有吸引力。当然，除非您同意同一程序使用多个库版本，否则在这种情况下，静态链接和 RPATH / RUNPATH(但不是 LD_LIBRARY_PATH)是您最好的选择。

*请注意，至少某些版本的 libtool都有添加RPATH条目的习惯，无论您是否要求它们-都需要提防。您可能需要修补项目中安装的libtool脚本，以避免这种情况。