[〜#〜] 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だけがこれをバグと見なしているようです http://bugs.archlinux.org/task/20059?project=1&opened=226 &関連する http:// bbs.archlinux.org/viewtopic.php?id=99807
/usr/local/lib
にライブラリを必要とするアプリケーションがRPATHに/usr/local/lib
を含めること、またはOSがすでにその設定を持っていることを期待することはより正しいですか? RPATHで$ Originに基づかないものを使用するという考えは嫌いです。
これは、システムの安定性とソフトウェアのパッケージ方法に影響を与えるため、衒学者の問題ではありません。
/ usr/local/libをデフォルトのパスに配置し、RedHatなどのLinuxバリアントでは「バグ」と見なす必要があることが提案されています。
この回答 https://stackoverflow.com/a/17653893 は、 http://の重要な部分を示しています。 linuxmafia.com/faq/Admin/ld-lib-path.html
多くのRedHat派生ディストリビューションは、通常、ファイル/etc/ld.so.confに/ usr/local/libを含めません。これはバグだと思います。/etc/ld.so.confに/ usr/local/libを追加することは、RedHatから派生したシステムで多くのプログラムを実行するために必要な一般的な「修正」です。
私はこれをRedHatで提起しましたが、今は同意しません。
ベンダーが/ usr/localにインストールするシステムでは、RedHatが提供するパッケージが/ 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(つまり、インストールの一部として制御する場所)にライブラリをインストールする必要があると思います。