[解決済み] Mac OS X で DYLD_LIBRARY_PATH を使ってもいいのでしょうか？また、それを使った動的ライブラリ検索アルゴリズムはどうなっていますか？

質問

動的ライブラリのパスは -install_name、@rpath、@loader_path で固定する必要があるため、DYLD_LIBRARY_PATH を使用しないようにという記事をいくつか読みましたが、どのようにすればよいですか？

LinuxとMac OS Xの両方で動作するプログラムを作るという意味では、Mac OS XのDYLD_LIBRARY_PATHは、LinuxのLD_LIBRARY_PATHと全く同じ働きをします。また、-install_nameと@rpathを付けないmakeファイルを（ほぼ）共有することができます。

• Mac OS XでDYLD_LIBRARY_PATHを使うのはOKですか？
• Mac OS Xでダイナミックライブラリが見つからない場合の検索アルゴリズムは？ current directory -> DYLD_LIBRARY_PATH directories ... ?

解決方法は？

ご指摘の通りです。 DYLD_LIBRARY_PATH のような動作をします。 LD_LIBRARY_PATH を他の *nix で使用することができます。しかし、もう一つの環境変数である DYLD_FALLBACK_LIBRARY_PATH .

一般に、これらは（OSXとLinuxの両方で）開発用途にのみ推奨されます。なぜなら、同じシンボルテーブルを持っていないライブラリで上書きすると、シンボル検索エラーが発生することがあるからです。この良い例は、VecLib（例：blas lapack）のデフォルトインストールをカスタムインストールで上書きしようとした場合です。この場合、システム VecLib にリンクされたアプリケーションで、以下のようなシンボルが見つからないというエラーが発生します。 DYLD_LIBRARY_PATH が設定されている場合は、その逆（カスタムアプリケーションでのシンボル検索エラー）となります。これは、システムのblas/lapackがATLASライブラリの完全な実装でないことが原因です。

DYLD_FALLBACK_LIBRARY_PATH を使用すると、これらの問題は発生しません。

ライブラリを標準的でない場所にインストールする場合。 DYLD_FALLBACK_LIBRARY_PATH の方がずっとまともです。これは、デフォルトのパスで提供されるライブラリからシンボルを探し、そこでシンボルが見つからなかった場合、指定されたパスにフォールバックします。

この処理の利点は、デフォルトのライブラリに対してコンパイルされたアプリケーションでシンボルのルックアップ・エラーが発生しないことです。

一般に、ライブラリを非標準的な場所にインストールする場合は、絶対パスを指定する必要があり、動的検索による曖昧さを排除します。