如何在 Linux 上获取 /etc/ld.so.conf 中的路径列表
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/6653635/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to get a list of paths in /etc/ld.so.conf on Linux
提问by Alexander Gladysh
What is the most portable and robust way to get the list of paths, configured by /etc/ld.so.confand files included from it? Parsing the file manually seems to be not a good idea — the format is likely to change in the future revisions.
获取路径列表、配置/etc/ld.so.conf文件和其中包含的文件的最便携和最健壮的方法是什么？手动解析文件似乎不是一个好主意——格式可能会在未来的修订版中发生变化。
To allow better understanding of the question, I will give you specific details below. Note that, despite these details, this is a general programming question, applicable to other situations.
为了更好地理解这个问题，我将在下面为您提供具体细节。请注意，尽管有这些细节，但这是一个通用的编程问题，适用于其他情况。
There is a program, called LuaRocks. It is a package manager for Lua programming language (somewhat like Ruby gems or Python eggs). LuaRocks packages are called "rocks".
有一个程序，叫做LuaRocks。它是 Lua 编程语言的包管理器（有点像 Ruby gems 或 Python Eggs）。LuaRocks 包被称为“岩石”。
As a convenience feature, LuaRocks allows a rock author to specify a list of external dependencies for a rock, formulated as a list of C header files and / or dynamic library files. (.so on Linux.) If the specified file does not exist, the rock can't be installed.
作为一个方便的特性，LuaRocks 允许摇滚作者指定摇滚的外部依赖列表，制定为 C 头文件和/或动态库文件的列表。（Linux 上的 .so。）如果指定的文件不存在，则无法安装 Rock。
Currently, on Linux, LuaRocks by default checks .so file existance by searching for the file in two hardcodedpaths, /usr/liband /usr/local/lib.
目前，在 Linux 上，LuaRocks 默认通过在两个硬编码路径中搜索文件来检查 .so 文件是否存在，/usr/lib以及.so 文件/usr/local/lib。
I believe that this is incorrect behaviour, and it is brokenby the recent changesin the Ubuntu and other Debian distributions.
我相信这是不正确的行为，并且它被Ubuntu 和其他 Debian 发行版的最近更改所破坏。
Update: the paths are not hardcoded per se, but are user-configurable in the config file. Still, IMO, not a best solution.
更新：路径本身不是硬编码的，而是用户可在配置文件中配置的。尽管如此，IMO 并不是最佳解决方案。
Instead (as I understand it), LuaRocks should look up file in the paths, specified by /etc/ld.so.confand files included from it.
相反（据我所知），LuaRocks 应该在路径中查找文件，由/etc/ld.so.conf其中包含的文件和文件指定。
(Now please re-read the question above ;-) )
（现在请重新阅读上面的问题;-)）
采纳答案by synthesizerpatel
You shouldn't need to parse /etc/ld.so.conf or any of the config files - if you run 'ldconfig', it will scan the configured directories and generate a cache file.
您不需要解析 /etc/ld.so.conf 或任何配置文件 - 如果您运行 'ldconfig'，它将扫描配置的目录并生成缓存文件。
Then, subsequently when you attempt a dlopen it'll automatically find the files by iterating through the cached library directories. Same thing with compiling and giving -lSomeLib, you shouldn't need to specify -L/my/other/path if you've got it configured in ld.so.conf(.d)
然后，随后当您尝试 dlopen 时，它会通过遍历缓存的库目录自动找到文件。与编译和提供 -lSomeLib 相同，如果在 ld.so.conf(.d) 中配置了 -L/my/other/path，则不需要指定 -L/my/other/path
autoconf accomplishes this by attempting to compile a test program that links to the shared library, but that's just a functional wrapper around the dlopen() call.
autoconf 通过尝试编译链接到共享库的测试程序来实现这一点，但这只是 dlopen() 调用的功能包装器。
So, while other methods may not necessarily be 'wrong', at the root of it attempting to link to the library or doing a dlopen() are the 'most right' ways of doing it.
因此，虽然其他方法不一定是“错误的”，但从根本上说，尝试链接到库或执行 dlopen() 是“最正确”的方法。
Consider this, if you attempt to link to a library in a directory that ISN'T cached in /etc/ld.so.cache, when you try to run the program it will fail because it won't be able to dlopen() the library!
考虑到这一点，如果您尝试链接到未缓存在 /etc/ld.so.cache 中的目录中的库，则当您尝试运行该程序时，它将失败，因为它无法执行 dlopen()图书馆！
Hence, any 'good' shared library will be in /etc/ld.so.cache and be linkable/dlopen()able, this means that gcc can use it to link and that the user-generated library or executable will be able to open it when it executes.
因此，任何“好的”共享库都将在 /etc/ld.so.cache 中并且可以链接/dlopen()，这意味着 gcc 可以使用它进行链接，并且用户生成的库或可执行文件将能够执行时打开它。
You can circumvent this by expressly setting the environment variable LD_LIBRARY_PATH, or LD_PRELOAD_PATH - but each of these has it's own caveats and should be avoided if possible for 'standard' use.
您可以通过明确设置环境变量 LD_LIBRARY_PATH 或 LD_PRELOAD_PATH 来规避这一点 - 但每个都有自己的警告，如果可能，应避免用于“标准”使用。
A good write-up on writing shared libraries covers some of these issues, and is a good read for anyone working on programmatic consuming of other-shared libraries. Ulrich Drepper's How to write shared libraries.
关于编写共享库的一篇很好的文章涵盖了其中的一些问题，对于从事其他共享库的编程消耗的任何人来说，这都是一本很好的读物。Ulrich Drepper 的如何编写共享库。
回答by nobody
According to the FHS, the following are valid locations for dynamic libraries:
根据FHS，以下是动态库的有效位置：
/lib*/
/opt/*/lib*/
/usr/lib*/
/usr/local/lib*/
(And most likely ~/lib*/as well.)
（而且很可能~/lib*/也是如此。）
All entries in my /etc/ld.so.conf.d/*conform to this. Some entries reference subdirectories below the FHS dirs, which probably means that you can use the libraries in there without path information.
我的所有条目都/etc/ld.so.conf.d/*符合这一点。某些条目引用 FHS 目录下的子目录，这可能意味着您可以在没有路径信息的情况下使用其中的库。
Now I don't know enough about LuaRocks. If you're limited to Lua-path-style globs (only ?), you cannot match these and have to parse the configs. Otherwise, you could just try to find them anywhere in these directories.
现在我对 LuaRocks 还不够了解。如果您仅限于 Lua 路径样式的 globs（仅限?），则无法匹配这些并且必须解析配置。否则，您可以尝试在这些目录中的任何位置找到它们。
This would break on non-FHS-conforming systems (only option: parse config) and if a directory is not included in the config, the installer might see libraries that the linker cannot find.
这会在不符合 FHS 的系统上中断（唯一选项：解析配置），如果配置中不包含目录，安装程序可能会看到链接器找不到的库。
These two seem acceptable to me, therefore I'd simply ignore the config and look at these dirs.
这两个对我来说似乎可以接受，因此我只是忽略配置并查看这些目录。
(Another possibility could be trying to link the library, this should automagically use the right path. However, this is platform-specific and maybe dangerous.)
（另一种可能性是尝试链接库，这应该会自动使用正确的路径。但是，这是特定于平台的，可能很危险。）
