>From what I can see, nothing is "broken" for him in the sense he is not >limited from doing anything >he was previously able to do.
Again, the matter is simple: what was working from Qt 4.8 up to Qt 5.4.2 is not working anymore with Qt 5.5.x. At least for me. >>Since Qt 4.8 and up to Qt 5.4.2 I was using the install_name_tool procedure >>as described here: >>http://doc.qt.io/qt-5/osx-deployment.html >>With prebuilt Qt 5.5.x clang64, QtFrameworks don't use absolute paths >>anymore, but instead they use @rpath, so calling something like this >> >>install_name_tool -change @rpath/QtCore.framework/Versions/5/QtCore >>@executable_path/../Frameworks/QtCore.framework/Versions/5/QtCore >>myapp.app/Contents/MacOs/myapp >>appears not to be working. (and not needed anymore) >> >Do not do that. You *want* the @rpath version; using anything but rpath-based >install names on >Apple platforms is an obscure edge case. If you think you >need that, you almost certainly don't. But it's what Trolltech/Nokia/Digia/QtCompany suggest to do ! Here again: http://doc.qt.io/qt-5/osx-deployment.html Deploying an OSX app is not only packing an application binary + the Qt libraries. My project has a plethora of other libraries coming from MacPorts and a number of QtPlugins loaded at runtime. So, I HAVE to perform install_name_tool on those ! (until MacPorts decide to go the rpath way as well...which I guess will make a lot of people upset) Anyway, see with your eyes. There are a lot of conditions to build on Qt4, QML, etc, but it should give you the idea of "my use case": https://github.com/mcallegari/qlcplus/tree/master/macx Start from macx.pro If you want to see what's inside my DMGs, download from here: http://sourceforge.net/projects/qlcplus/files/4.9.1/ _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
