[Development] Qt 5.5.0 build issues on OS X : rpath

[Massimo Callegari]

>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/