在下面FHS，系统软件包（例如 RPM）将库安装到/usr/lib（或/usr/lib64）。同样，使用旧的“ configure;make;make install”例程编译的库（不属于系统发行版的一部分）默认安装到/usr/local/lib（或/usr/local/lib64）。
一般来说，要求用户更改 LD_LIBRARY_PATH 或ld.so.conf他们安装的应用程序被认为是不好的形式。参见示例：
http://web.archive.org/web/20060719201954/http://www.visi.com/~barr/ldpath.html
但是，这条规则不应该/usr/local/lib是一个例外吗？
如果是这种情况，为什么许多/大多数发行版默认情况下不包含/usr/local/lib在库搜索路径中？到目前为止，似乎只有 ArchLinux 认为这是一个 bug 查看http://bugs.archlinux.org/task/20059?project=1&opened=2263
及相关的http://bbs.archlinux.org/viewtopic.php?id=99807
对于需要将库/usr/local/lib包含/usr/local/lib在其 RPATH 中的应用程序来说，还是期望操作系统已经具有该设置更正确？我不喜欢在 RPATH 中使用任何不基于 $ORIGIN 的东西。
这不是一个迂腐的问题，因为它对系统稳定性以及软件的打包方式有影响。
答案1
有人建议 /usr/local/lib 应该位于默认路径上，并且在 Red Hat 等 Linux 变体中，它应该被视为“错误”，但事实并非如此。
这个答案https://stackoverflow.com/a/17653893 指出了其中的显着部分http://linuxmafia.com/faq/Admin/ld-lib-path.html
许多 Red Hat 派生发行版通常不会在文件 /etc/ld.so.conf 中包含 /usr/local/lib。我认为这是一个错误，将 /usr/local/lib 添加到 /etc/ld.so.conf 是在 Red Hat 派生系统上运行许多程序所需的常见“修复”。
我向红帽提出了这个问题，但现在我不同意。
在供应商安装到 /usr/local 的系统上，Red Hat 提供的软件包永远不会安装到 /usr/local，答案是不同的。在这些系统上，可以合理地预期 /usr/local/lib 位于默认搜索路径上。
Red Hat 指出 /usr/local/lib 不应该位于默认搜索路径上，因为添加到那里的任何库都可以被 RPM 和 yum 获取。
我进一步调查了这一点。如果您在 /usr/local/lib 中安装您自己版本的系统库，那么它可以满足您通常通过 RPM 或 yum 安装的另一个系统包的依赖关系。显然这会影响系统稳定性。更糟糕的是，它会非常巧妙地做到这一点。 yum check 可能会报告您拥有所需的所有软件包的所有供应商版本，但没有注意到您拥有 /usr/local/lib 中重要内容的自己版本。
在使用不同包管理器的系统上，这可能不适用。
对于在 RPATH 中放入什么内容，我没有完整的答案。但是，我认为您应该避免依赖 /usr/local/lib 中的库，而是尽可能将它们安装到 /opt （即您在安装过程中控制的地方）。