Question

获取/etc/ld.so.conf配置的路径列表及其中包含的文件的最便携，最健壮的方法是什么？手动解析文件似乎不是一个好主意 - 格式可能会在未来的版本中发生变化。

为了更好地理解这个问题，我将在下面给出具体细节。请注意，尽管有这些细节，但这是一个通用编程问题，适用于其他情况。

有一个名为LuaRocks的程序。它是Lua编程语言的包管理器（有点像Ruby gems或Python eggs）。 LuaRocks包被称为“岩石”。

作为一个便利功能，LuaRocks允许摇滚作者指定一个摇滚的外部依赖项列表，表示为C头文件和/或动态库文件的列表。（.so在Linux上。）如果指定的文件不存在，则无法安装摇滚。

目前，在Linux上，LuaRocks默认通过在两个~~硬编码~~路径/usr/lib和/usr/local/lib中搜索文件来检查.so文件是否存在。

我认为这是不正确的行为，最近的broken是Ubuntu和其他Debian发行版中的changes。

更新：路径本身不是硬编码的，但在配置文件中是用户可配置的。仍然，IMO，不是最好的解决方案。

相反（据我所知），LuaRocks应该在/etc/ld.so.conf指定的路径中查找文件，并从中包含文件。

（现在请重新阅读上面的问题;-)）

Answer 1

您不需要解析/etc/ld.so.conf或任何配置文件 - 如果您运行'ldconfig'，它将扫描配置的目录并生成缓存文件。

然后，当您尝试执行dlopen时，它将通过迭代缓存的库目录自动查找文件。编译和提供-lSomeLib也是一样，如果你已经在ld.so.conf（.d）中配置了它，则不需要指定-L / my / other / path

autoconf通过尝试编译链接到共享库的测试程序来实现这一点，但这只是围绕dlopen（）调用的功能包装器。

所以，虽然其他方法可能不一定是'错误的'，但它的根源是尝试链接到库或执行dlopen（）是“最正确”的方法。

考虑到这一点，如果您尝试链接到未在/etc/ld.so.cache中缓存的目录中的库，当您尝试运行该程序时，它将失败，因为它将无法dlopen（）图书馆！

因此，任何'好'的共享库都在/etc/ld.so.cache中并且是可链接的/ dlopen（），这意味着gcc可以使用它来链接，并且用户生成的库或可执行文件将能够在执行时打开它。

您可以通过明确设置环境变量LD_LIBRARY_PATH或LD_PRELOAD_PATH来规避这一点 - 但是每个都有它自己的警告，如果可能的话，应该避免使用“标准”。

关于编写共享库的一篇好文章涵盖了其中的一些问题，对于从事程序化消费其他共享库的人来说，这是一本很好的读物。 Ulrich Drepper's How to write shared libraries

Answer 2

根据FHS，以下是动态库的有效位置：

/lib*/
/opt/*/lib*/
/usr/lib*/
/usr/local/lib*/

（最有可能~/lib*/。）

我/etc/ld.so.conf.d/*中的所有条目都符合此要求。有些条目引用FHS目录下的子目录，这可能意味着您可以在那里使用库而不需要路径信息。

现在我对LuaRocks了解不多。如果你只限于Lua-path-style globs（只有?），你就无法匹配这些并且必须解析配置。否则，您可以尝试在这些目录中的任何位置找到它们。

这将违反非FHS一致的系统（仅选项：解析配置），如果配置中未包含目录，安装程序可能会看到链接器无法找到的库。

这两个似乎对我来说是可以接受的，因此我只是忽略配置并查看这些目录。

（另一种可能是尝试链接库，这应该自动使用正确的路径。但是，这是特定于平台的，可能很危险。）