1 
install_name_tool -change /usr/local/lib/testlib.dylib  "$TARGET_BUILD_DIR"/../../testlib.dylib "$PRODUCT_NAME"

xcodeで実行スクリプトに入れると、ダイナミックライブラリのルックアップパスが変更されると上記のように言われました。これは、ターミナルウィンドウに次のように入力することで確認できます

otool -L /drag/the/executable/here/and/its/filepath/will/show/up/testlib

出力は次のようになります

/previous/filepath:
/usr/local/lib/testlib.dylib (compatibility version 1.0.0, current version 1.0.0)
./anothertestlib.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

私の質問は、install_name_toolコマンドが機能しないのはなぜですか？現在はそうではありませんが、testlibプロジェクトがクライアントプロジェクトのターゲット依存関係であったときに実行されました。これで、.dylibをクライアントプロジェクトにドラッグしました。ルックアップパスはusr/local/libにとどまります。

また、usr / local / libとは何ですか、なぜシステムは私のdylibがそこにあると見なし、どのようにしてそこに到達したのですか？

4

1 に答える 1

1

install_name_tool はパス文字列を上書きすることで機能するため、新しいものは元のものと同じ長さかそれより短くする必要があります。

「/usr/local/lib/testlib.dylib」の長さは 28 文字であり、「「$TARGET_BUILD_DIR」/../../testlib.dylib」の長さは少なくとも 20 文字であるため、$TARGET_BUILD_DIR 変数が文字列に展開される場合9 文字以上の場合、置換はおそらく長すぎて使用できません。

おそらく、フラグ -headerpad_max_install_names をリンカーに追加して、各パスの後にパディングを追加し、より長い置換を可能にするスペースが存在するようにすることができるためです (最大 1,024 文字と考えています)。install_name_tool が失敗しているため、これはおそらく使用されていません。

/usr/local/lib パスに関しては、技術的には /usr (/usr/bin、/usr/lib など) は、任意のマシンに適用され、ネットワークにマウントできるソフトウェアに使用されます。ローカル ルート (/usr/local/bin、/usr/local/lib) は、ローカル マシンだけに固有のものです。実際には、OS ディストリビューション ユーザー /usr およびカスタム インストールを介して提供されるパッケージが /use/local を使用する場合が多くなります。ほとんどの場合、それは問題ではありません。特に Mac では、Homebrew パッケージ マネージャーは /usr/local ルートを使用します (MacPorts は /opt と Fink /sw を使用します)。

最初にインストールするために行ったことが、他のオプションよりもその場所を使用したことがたまたまありました。しかし、必要なものがどこを見ればよいかを知っている限り、それは多かれ少なかれ有効な場所ではありません。

于 2013-02-18T10:38:30.623 に答える