長い話を短くで共有ライブラリへのシンボリックリンクを配置する方が良い理由、または/etc/lib(64)/
*.confファイルを生成する方が良い理由/etc/ld.so.conf.d/
.conf ファイル
/opt/foo/
に私のカスタムバイナリがあり、独自の共有ライブラリが付属しているとしましょう。 (私が知っている)一般的な方法は、/etc/ld.so.conf.d/foo.conf
次のようにファイルを配置することです。
# Link foo libraries. This file is included in /etc/ld.so.conf
/opt/foo/lib
/opt/foo/otherlibs
それからldconfig
。
シンボリックリンク
/usr/lib
しかし、次のように私のライブラリを(またはlib64)にリンクすることもできることがわかりました。
for f in /etc/foo/{lib,otherlibs}/*; do
ln -s $f /usr/lib64/$(basename $f)
done
それ以降はもう走る必要はありませんldconfig
。
これら2つの方法の利点/欠点は何ですか?
アプリケーションまたはライブラリのバージョンをアップグレードするときに「symlink」メソッドを処理するのはそれほど簡単ではないようです。全体的に、".conf"アプローチは私にもっとモジュール化され、Linuxに近いようです。
特定のライブラリを暗号化(実行時のみ復号化)する必要があるため、この状況が発生します。ldconfig
暗号化された場合(まだELF形式)、ライブラリが認識されないため、私に適した唯一の方法は、特定の* .soファイルへのリンクを次の場所に配置することでした。/usr/lib64
答え1
一般に、「属してい/usr
ない/usr/local
」すべてはディストリビューションに属します。ここにファイル(さらにはシンボリックリンク)を追加しないでください。
新しい設定ファイルを追加すると、/etc/ld.so.conf.d
メンテナンスが簡単になります。変更はパッケージマネージャによってキャンセルされませんが、すべてのシステム管理者が簡単に管理できます。
暗号化要件をきれいに満たすことはより複雑です。 1つのアプローチは、ファイルに指定されたディレクトリにスタブライブラリを置き、実行/etc/ld.so.conf.d
時に復号化を処理することです。