OSX 10.11.1のシェルでDYLD_FALLBACK_LIBRARY

典型的な@rpath以外のディレクトリで動的ライブラリを使用した単体テストに使用されるシェルスクリプトでは、以前にDYLD_FALLBACK_LIBRARY_PATHを設定して、ライブラリを含むディレクトリを設定できました。10.11.1では、bashはこの環境変数を設定する試みを無視するようです。

$ sh -x testscript.sh
+ DYLD_FALLBACK_LIBRARY_PATH=/Users/something/testinglibs
+ export DYLD_FALLBACK_LIBRARY_PATH
+ exec printenv

そして、DYLD_FALLBACK_LIBRARY_PATHはprintenvの出力に存在しません。

これは10.11のシェルのセキュリティ関連のハックですか？manページやオンラインに記載されているこの変更を見つけることができませんでした。

— 男
ソース

うinstall_name_toolのヘルプは？

— SaaruLindestøkke2017

確かに、install_name_toolは永続的なソリューションです（ビルド環境をセットアップするために実際にスクリプトを作成しました）。開発環境で迅速なテストとデバッグを行うには、ライブラリの一時的なコピーを作成し、@ rpathの変更をハッキングし、手動での変更を忘れる必要があるのは面倒です。DYLD_FALLBACK_LIBRARY_PATHとDYLD_LIBRARY_PATHは、これらの不定期の開発/テストサイクルに役立ちました。

— Guy

これは、El Capitanで導入されたシステム整合性保護です。

ドキュメントがであるこのアップルから

基本的に、アップルが提供するすべてのOS X実行可能ファイルが保護されます。および（以前のドキュメントから）

NSTaskを使用してバンドルでヘルパープロセスを起動したり、exec（2）コマンドを呼び出したりして、システム整合性保護によって制限されたプロセスの子プロセスを生成すると、その子プロセスのMach特殊ポートがリセットされます。保護されたプロセスを起動すると、DYLD_LIBRARY_PATHなどの動的リンカー（dyld）環境変数がすべて削除されます。

この場合、shは保護されています

— user151019
ソース

ポインタをありがとう！私は、SIPのカーネルおよびその他のファイルシステム保護に焦点を合わせていました。この変更に気づかなかった。

— ガイ

さて、これは現象の起源を説明していますが、今、インストールされていないライブラリをどのようにテストするべきですか？make checkつまり、共有ライブラリが必要なときに、El Capitan でどのように書くことができますか？

— 2015年

autoconf経由のほとんどのmakeは、まだ書き込み可能な/ usr / localになるはずです

— 。/usrの

dyld環境変数が消えた理由を理解しようとする時間を無駄にした後で誰かがこれを見つけた場合は、dyld / SIPの相互作用を文書化するようにAppleにバグを提出することを検討してください。私はすでにそうしました、そして、バグは番号rdar：// 30755019を得ました。（私は彼らが他のそのような罠を文書化することを考えてくれることを願っています...）

— hmijailは辞任者を悼みます'28

（私はdyldのマンページにSIPインタラクションを文書化することを意味しました。これは、この執筆時点では完全に

— 母国語です

OSX 10.11.1のシェルでDYLD_FALLBACK_LIBRARY_PATHを設定できない