下ＦＨＳ、システム パッケージ (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だけがこれをバグと見なしているようです。http://bugs.archlinux.org/task/20059?project=1&opened=2263
および関連するhttp://bbs.archlinux.org/viewtopic.php?id=99807
ライブラリを必要とするアプリケーションをRPATH に/usr/local/lib含めること/usr/local/lib、または OS に既にその設定があることを期待することがより適切でしょうか? 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 が含まれていません。これはバグであると考えており、/etc/ld.so.conf に /usr/local/lib を追加することは、Red Hat 由来のシステムで多くのプログラムを実行するために必要な一般的な「修正」です。
私は Red Hat にこの件を提起しましたが、今は同意できません。
Red Hat が提供するパッケージは、ベンダーが /usr/local にインストールするシステムでは /usr/local にインストールされることはありません。答えは異なります。これらのシステムでは、/usr/local/lib がデフォルトの検索パスにあると予想できます。
Red Hat は、そこに追加されたライブラリは RPM と yum によって取得される可能性があるため、/usr/local/lib をデフォルトの検索パスに配置するべきではないと指摘しました。
これをさらに調査しました。/usr/local/lib に独自のバージョンのシステム ライブラリをインストールすると、通常 RPM または yum 経由でインストールする別のシステム パッケージの依存関係を満たす可能性があります。明らかに、これはシステムの安定性に影響を与える可能性があります。さらに悪いことに、影響は非常に微妙です。yum check は、必要なすべてのパッケージのベンダー バージョンがすべてあることを報告しますが、/usr/local/lib に重要なものの独自のバージョンがあることに気付かない可能性があります。
別のパッケージ マネージャーを使用しているシステムでは、これは適用されない可能性があります。
RPATH に何を入れるべきかについて、完全な答えはありません。ただし、/usr/local/lib 内のライブラリに依存することは避け、代わりに、可能な限り /opt (つまり、インストールの一部として制御できる場所) にインストールするべきだと思います。