web-dev-qa-db-ja.com

共有ライブラリがロードされていません。ルートの下でのみロード

/opt/...フォルダーにある共有ライブラリを必要とする実行可能ファイルがあります。 LD_LIBRARY_PATHの下の/etc/environmentにパスを含め、source /etc/environmentを使用して更新しました。ルート権限なしでこの実行可能ファイルを実行すると、libxxx.so: cannot open shared object file: No such file or directoryというエラーが表示されます。しかし、Sudoで実行すると、実行されます。問題はありますが、ライセンスはrootユーザーではないため、ライセンスに関するエラーがスローされます。通常のユーザーがファイルを作成および削除できるように、/opt/...の権限を変更しました。しかし、それは助けにはなりません。何が問題なのか、どうすれば修正できますか？

permissionsrootenvironment-variablesshared-library
3
user592748

/etc/environmentはログイン時に解釈されます。したがって、/etc/environmentに加えた変更を確認する正しい方法は、ログアウトして再度ログインすることです。

Sudoは、ログインをルートとして部分的にエミュレートするため機能します（Sudo -iはさらに正確にログインをエミュレートします）。

source /etc/environmentは機能しません。sourceは、指定されたファイルをシェルスクリプトとして解釈するようシェルに指示するシェルコマンドであるためです。問題は：/etc/environmentはシェルスクリプトではありません。次の形式の環境変数の名前と値のペアのリストです。

name="value"

その行は、シェルの場合、グローバル変数の定義であり、シェル自体のみが見ることができます。シェルから実行されたプログラムはそれを見ることができません。環境変数を定義する正しい方法は、export Shellコマンドを使用することです。

export name="value"

したがって、ログアウトせずに真新しいLD_LIBRARY_PATHを使用したい場合は、source /etc/environmentの代わりに次のコマンドを実行する必要があります。

export LD_LIBRARY_PATH="/opt/..."

UPDATE：LD_LIBRARY_PATHは、/etc/environmentのため、ssh-agentに設定できません。詳細については、 バグ＃47958 および 環境変数 に関するUbuntu wikiページを参照してください。 Wikiページで指定されているように、回避策が存在し、/etc/ld.so.conf.dを使用しています。

たとえば、次の内容の/etc/ld.so.conf.d/opt.confを作成できます。

# Paths for my cool libraries
/opt/...

これは回避策としてリストされていますが、ld.so.conf.dは実際にそのような設定に最も適切な場所です。

3
Andrea Corbellini