在下面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 （即您在安裝過程中控制的地方）。