获取由/etc/ld.so.conf配置的路径列表和其中包含的文件的最可移植和最健壮的方法是什么?手动解析文件似乎不是一个好主意——格式很可能在未来的版本中改变。
为了更好地理解这个问题，我将在下面给出具体的细节。请注意，尽管有这些细节，但这是一个通用的编程问题，适用于其他情况。
有一个程序叫做luarrocks。它是Lua编程语言的包管理器(有点像Ruby gems或Python eggs)。luarrocks包被称为"rocks"。
作为一个方便的功能，luarrocks允许一个岩石作者指定一个岩石的外部依赖列表，以C头文件和/或动态库文件的列表形式表示。（.在Linux上也是如此。)如果指定的文件不存在，则无法安装。
目前，在Linux上，luarrocks默认通过在两个硬编码路径/usr/lib和/usr/local/lib中搜索文件来检查。so文件是否存在。
我相信这是不正确的行为，它被Ubuntu和其他Debian发行版最近的变化所打破。
更新:路径本身不是硬编码的，但用户可以在配置文件中配置。不过，在我看来，这不是最好的解决方案。
相反(正如我所理解的)，luarrocks应该在路径中查找文件，由/etc/ld.so.conf指定和包含的文件。
(现在请重新阅读上面的问题;-))
你不需要解析/etc/ld.so.conf或任何配置文件-如果你运行'ldconfig'，它将扫描配置的目录并生成一个缓存文件。
然后，当您尝试dlopen时，它会通过迭代缓存的库目录自动找到文件。编译和给出-lSomeLib也是一样，如果你已经在ld.so.conf(.d)
中配置了-L/my/other/path，你就不需要指定-L/my/other/path了autoconf通过尝试编译一个链接到共享库的测试程序来实现这一点，但这只是一个围绕dlopen()调用的功能性包装。
所以，虽然其他方法不一定是"错误的"，但从根本上说，试图链接到库或执行dlopen()是"最正确"的方法。
考虑一下，如果你试图链接到一个不在/etc/ld.so.中缓存的目录中的库缓存，当您尝试运行程序时，它将失败，因为它将无法打开()库!
因此，任何"好的"共享库都将在/etc/ld.so.中缓存和linkable/dlopen()able，这意味着GCC可以使用它来链接，并且用户生成的库或可执行文件在执行时能够打开它。
您可以通过明确设置环境变量LD_LIBRARY_PATH或LD_PRELOAD_PATH来规避这一点，但是每个环境变量都有自己的警告，应该尽可能避免"标准"使用。
关于编写共享库的一篇很好的文章涵盖了其中的一些问题，对于任何从事程序化使用其他共享库的工作的人来说，这是一本很好的读物。如何编写共享库
根据FHS，以下是动态库的有效位置:
/lib*/
/opt/*/lib*/
/usr/lib*/
/usr/local/lib*/
(很可能还有~/lib*/)
我的/etc/ld.so.conf.d/*中的所有条目都符合这一点。有些条目引用FHS目录下的子目录，这可能意味着您可以在没有路径信息的情况下使用其中的库。
现在我对luarrocks的了解还不够。如果您仅限于lua路径风格的globs(仅?)，则无法匹配这些globs，必须解析配置。否则，您可以尝试在这些目录中的任何地方找到它们。
这将在不符合fhs的系统上中断(唯一选项:parse config)，如果一个目录不包含在配置中，安装程序可能会看到链接器无法找到的库。
这两个对我来说似乎是可以接受的，因此我简单地忽略配置并查看这些目录。
(另一种可能是尝试链接库，这应该自动使用正确的路径。但是，这是特定于平台的，可能很危险。