> On Sep 29, 2015, at 2:35 AM, Massimo Callegari <[email protected]> > wrote: > > >> 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.
Because it was previously using a configuration that was extremely uncommon in real world Mac development. Now it's fixed and you are required to adapt your project in accordance. >>> 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 As I said, the documentation needs to be updated. I'll update it so that it provides more information and better corresponds with what I said earlier. > 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) That's the "broken dependency" case. Why MacPorts has a no-rpath policy on a platform where you copy the actual libraries into your product, I have no idea. Maybe try Homebrew, they tend to be more up-to-date anyways. > 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/ You can easily have a build setup that works for all Qt versions from 4.8 through 5.5. Simply use install_name_tool to transform dynamic library install names to @rpath-based ones as always (if they are already in the latter form, the commands will do nothing), and add @loader_path/../Frameworks to your own binaries -- simple as that. It'll work with 4.8, 5.4, 5.5... -- Jake Petroules - jake.petroules at petroules.com
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
