I have an executable with the following dependencies:
GaribenkaMac:
@rpath/libwx_osx_cocoau_richtext-3.2.0.dylib (compatibility version 0.0.0, current version 0.2.1)
@rpath/libwx_osx_cocoau_xrc-3.2.0.dylib (compatibility version 0.0.0, current version 0.2.1)
@rpath/libwx_osx_cocoau_html-3.2.0.dylib (compatibility version 0.0.0, current version 0.2.1)
@rpath/libwx_osx_cocoau_qa-3.2.0.dylib (compatibility version 0.0.0, current version 0.2.1)
@rpath/libwx_osx_cocoau_core-3.2.0.dylib (compatibility version 0.0.0, current version 0.2.1)
@rpath/libwx_baseu_xml-3.2.0.dylib (compatibility version 0.0.0, current version 0.2.1)
@rpath/libwx_baseu_net-3.2.0.dylib (compatibility version 0.0.0, current version 0.2.1)
@rpath/libwx_baseu-3.2.0.dylib (compatibility version 0.0.0, current version 0.2.1)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1575.17.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)
I've copied these dylib files into the Contents/MacOS/ folder of the bundle and used commands like this one to link them:
$ install_name_tool -change /Users/username/Desktop/wxWidgets.nosync/Library/wxWidgets-3.2.2.1/macbuild/lib/libwx_osx_cocoau_qa-3.2.0.dylib /Users/username/Desktop/Garibenka.nosync/Garibenka.app/Contents/MacOS/libwx_osx_cocoau_qa-3.2.0.dylib /Users/username/Desktop/Garibenka.nosync/Garibenka.app/Contents/MacOS/GaribenkaMac
But this seems to have no effect. The app still throws "Library not loaded" error. I have no idea, what I should do, and the documentation didn't really help (I'm very new to Mac, and this all is quite confusing to me).
What should I do to fix this?
My experience is that there are three common causes of ‘library not found’ problems:
-
The dynamic linker was unable to find your library.
-
It rejected your library due to an install name mismatch.
-
The trusted execution system prevented it from loading the library.
In the first case, the crash report should include info about where the dynamic linker looked.
In the second case, you can dump the install name of both the importer and the importee to confirm that they’re the same [1]. See Dynamic Library Identification for info on how to do that.
The most common cause of the third case is that your libraries are signed incorrectly; for example, you might be trying to import a library that’s signed by a different team. My general recommendation is that you sign all of the code you ship as your code.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] There’s some leeway here, but if you follow one of the two patterns recommended by Dynamic Library Identification then the importer and importee install name will be identical.