OS Xの下での共有オブジェクトの位置は、時々トリッキーです。 dlopen()に直接電話すると、ライブラリーへの絶対パスを自由に指定することができます。これはうまくいきます。しかし、ライブラリをロードして別のライブラリをロードする必要がある場合（あなたの状況のように見える）、ライブラリがどこにあるかを直接パスで指定することはできません。
に設定できる環境変数があります。は、メインプログラムを実行しているため、動的ローダーにどこを検索するかを指示します。一般的に、これらは悪い考えです（ただし、OS Xシステムのman dyldコマンドを使用してそれらについて読むことができます）。
OS Xダイナミックライブラリが作成されると、インストール名が与えられます。この名前はバイナリに埋め込まれており、otoolコマンドで見ることができます。 otool -L mach-o_binaryは、ファイル名を指定するmach-oバイナリの動的ライブラリ参照をリストします。これは、例えばプライマリ実行ファイルまたはdylibにすることができます。
ダイナミックライブラリが別の実行可能ファイル（プライマリ実行可能ファイルまたは別のdylib）に静的にリンクされている場合、リンクされているdylibの予想される場所は、書き込まれた場所に基づいています作成された変更、またはその後に適用された変更）。あなたの訴訟において、phys_services.soは、libphys-services.dylibに、静的リンクされているようです。だから開始するにはotool -L phys_services.soを実行して正確なのdylibがどこにあるかを見てください。
install_name_toolコマンドを使用して、ライブラリの予想される場所を変更することができます。それは、静的にリンクされる前にdylibに対して実行することができます（その場合は何もしない）、またはそれらの期待を書き換えるためにロードする実行可能ファイルに対して実行することができます。これのコマンドパターンはinstall_name_tool -change <old_path> <new_path>です。たとえば、otool -L phys_services.soに/usr/lib/libphys-services.dylibと表示されていて、あなたの疑問にお答えしたいと思った場合は、install_name_tool -change /usr/lib/libphys-services.dylib @rpath/lib/libphys-services.dylib phys_services.soでそれを行います。
dyldのマニュアルページ（man dyld）は、@rpathがどのように使用されているか、そして他のマクロ@loader_pathと@executable_pathを教えてくれます。
出典
2014-03-21 13:30:43
mah
私はrubyでbinding.pryを使用しながらxcode 8をインストールした後も同じ問題がありました。ルビーを再インストールした後、すべて正常に動作しました。複雑ではありませんが、ママからの正しい答えです。私のシステムを最近更新したので、 'rvm requirements'も私を助けました。 – Johannes