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

[Jake Petroules]

> On Sep 29, 2015, at 2:35 AM, Massimo Callegari <massimocallegari at yahoo.it> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150929/7babd4ec/attachment.html>