71

ダイナミックライブラリのパスは-install_name、@ rpath、および@loader_pathを使用して修正する必要があるため、DYLD_LIBRARY_PATHの使用を推奨しない記事をいくつか読みました。

LinuxとMacOSXの両方で実行されるプログラムを作成するという点では、Mac OS XのDYLD_LIBRARY_PATHは、LinuxのLD_LIBRARY_PATHとまったく同じように機能します。そして、-install_nameと@rpathを持たない（ほぼ）同じmakeファイルを共有できます。

  • Mac OS XでDYLD_LIBRARY_PATHを使用しても大丈夫ですか？
  • バイナリがダイナミックライブラリを見つけられない場合のMacOSXのダイナミックライブラリ検索アルゴリズムは何ですか？現在のディレクトリ->DYLD_LIBRARY_PATHディレクトリ...？
4

3 に答える 3

85

ご指摘のとおり、他の *nix とDYLD_LIBRARY_PATH同じように動作します。LD_LIBRARY_PATHただし、 と呼ばれる別の環境変数を確認する必要がありますDYLD_FALLBACK_LIBRARY_PATH。

一般に、これらは (osx と linux の両方で) 開発用にのみ推奨されます。これは、同じシンボル テーブルを持たないライブラリでオーバーライドすると、シンボル ルックアップ エラーが発生する可能性があるためです。これの良い例は、VecLib のデフォルトのインストール (例: blas lapack) をカスタム インストールでオーバーライドしようとする場合です。が設定されている場合は、システム VecLib にリンクされたアプリケーションでシンボルが見つからないというエラーが発生し、DYLD_LIBRARY_PATH設定されていない場合はその逆 (カスタム アプリケーションでのシンボル検索エラー) が発生します。これは、システム blas/lapack が ATLAS ライブラリの完全な実装ではないためです。

DYLD_FALLBACK_LIBRARY_PATHこれらの問題は発生しません。

ライブラリを非標準の場所にインストールする場合DYLD_FALLBACK_LIBRARY_PATHは、はるかに正気です。これにより、デフォルト パスで提供されるライブラリ内のシンボルが検索され、そこでシンボルが見つからない場合は、指定されたパスに戻ります。

利点は、このプロセスによって、既定のライブラリに対してコンパイルされたアプリケーションでシンボル ルックアップ エラーが発生しないことです。

一般に、ライブラリが非標準の場所にインストールされている場合は、動的検索のあいまいさを解消する絶対パスを指定する必要があります。

于 2010-07-03T18:55:30.127 に答える