On Thursday May 28 2015 15:38:41 Nuno Santos wrote: >MACKIE:64 nsantos$ file >audiolab.vst/Contents/Frameworks/QtCore.framework/Versions/5/QtCore >audiolab.vst/Contents/Frameworks/QtCore.framework/Versions/5/QtCore: Mach-O >64-bit dynamically linked shared library x86_64
That shows QtCore was not built with the -bundle flag, which is appropriate. Forget my whole ramble about bundles and shared libraries; I overlooked that the failing image is a Qt framework that should be linked as a shared library (and not as a bundle). I'm a bit confused as to what the plugin is you're trying to build: is in fact audiolab.vst that plugin? Are you bundling Qt within that plugin bundle, maybe because the host application does not use Qt itself? Maybe it's the use of @executable_path that got me confused. As far as I know, this is interpreted relative to the running application, the host loading the plugin, which could be the most straightforward explanation why you get an "image not found" error. Cf. https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath . >>> I can also observe that the bundle does load, if I don’t run macdeployqt on >>> it. But i’m also sure that it won’t open on another computer without Qt >>> installed on the same path. Yes, that would correspond with my latest idea: without macdeployqt the "rpaths" in your binary aren't changed as if it's an application. >Xcode has a template for plugin bundles. I've only used those templates with an older Xcode version, and there you had to do certain things by hand, including setting the "rpath". At least I could never figure out if there was an automatic way to obtain a bundle or framework that could be embedded in an app bundle. >macx:{ > CONFIG += plugin > QMAKE_LFLAGS_PLUGIN -= -single_module -dynamiclib > QMAKE_LFLAGS_PLUGIN += -bundle > QMAKE_POST_LINK = mv -f $(TARGET) $$TARGET > OTHER_FILES += Info.plist >} > >This produces a dylib which I rename to target as you can see in the following >output: Just as a side-note: if you do this with cmake, you get a .so, probably to make it clear the linker won't be able to use it but possibly only to increase the chances that cross-platform code will find the file without having to consider a platform-specific extension. >The bundle structure is the following: > >target.vst > - PkgInfo > - MacOS > - target (dylib without extension) > - Resources > >So basically what I do is to manually copy the output lib without the >extension inside the MacOS dir. > >Then I point the host program to search for plugins in the folder where this >is contained, and it gets found. Yes, and if "target" instructs the dynamic loader to look for Qt frameworks relative to the host application executable (host.app/Contents/MacOS/host), it won't find them. According to the wiki page above, you'll need to use @loader_path instead of @executable_path You'll probably need to do something like %> install_name_tool -id @loader_path/../Frameworks/QtGui.framework/Versions/5/QtGui <path-to-bundle-Frameworks-dir>/QtGui.framework/Versions/5/QtGui %> install_name_tool -change @executable_path/../Frameworks/QtGui.framework/Versions/5/QtGui @loader_path/../Frameworks/QtGui.framework/Versions/5/QtGui <path-to-audiolab>/audiolab Running `otool -L` on QtGui or audiolab will help you hunt down the entries that have to be changed. If it's not that, there's still the slight possibility that the image that supposedly isn't found can in fact not be loaded because it depends itself on a shared library that somehow cannot be found. This you can check by doing the equivalent of Linux's ldd command: %> otool -L <image-that-cannot-be-found> Good luck R _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
