如何在Linux上获取/etc/ld.so.conf中路径列表

2017-4-13 12:22:39
收藏：0
阅读：167
评论：2

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

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

有一个名为LuaRocks的程序。它是Lua编程语言的软件包管理器（有点像Ruby gems或Python eggs）。LuaRocks程序包称为"rocks"。

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

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

我认为这是不正确的行为，由于Ubuntu和其他Debian发行版的最近更改，这是破碎的。

更新：路径不是硬编码的，而是在配置文件中可以配置的。仍然，我认为这不是最好的解决方案。

相反（就我所理解的），LuaRocks应该在/etc/ld.so.conf及其包含的文件指定的路径中查找文件。

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

原文链接 https://stackoverflow.com/questions/6653635

点赞
stackoverflow用户805875
stackoverflow用户805875

根据FHS规范，动态库的有效位置如下：

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

(很可能也包括~/lib*/。)

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

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

这将在非FHS一致的系统上中断(唯一选项:解析配置文件)，并且如果目录未包含在配置文件中，则安装程序可能会看到链接器找不到的库。

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

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

2011-07-11 18:02:25
stackoverflow用户210613
stackoverflow用户210613

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

然后，当你尝试 dlopen 时，它会通过迭代缓存的库目录自动找到文件。如果在 ld.so.conf(.d) 中进行了配置，那么在编译并使用 -lSomeLib 进行链接时，你不需要指定 -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。

2011-07-11 18:07:00

作者:

stackoverflow用户6236

stackoverflow用户6236
推荐文章