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

Jake Petroules jake.petroules at petroules.com
Tue Sep 29 10:16:32 CEST 2015


> On Sep 28, 2015, at 2:30 PM, Massimo Callegari <massimocallegari at yahoo.it> wrote:
> 
> On Monday 28 September 2015 19:09:11 Massimo Callegari wrote:
>>> But please guys, when introducing such an important change, you are warmthly
>>> invited to mention it in a visible place.
> 
>> It's in the changelog.
> 
>> But I confess the line you're referring to does not indicate that anything 
>> should break. Qt being build with rpath should enable more, but not remove 
>> functionality that existed.
> 
>> Can you explain what broke for you?

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.

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

We need to start code-signing our official releases to stop people from doing this. :)

> If Qt is built with -rpath, then an application is in charge to tell Qt how to resolve @rpath, thus the need of adding QMAKE_LFLAGS += -Wl,-rpath, at executable_path/../Frameworks
> 
> I might got it wrong, but at least this is what I got and how I made it work back again.
> If there is a proper and official way to deploy any Qt5 version in a unique way, please point me to the right documentation.

That is the right way and always has been. Ideally you should use:

	QMAKE_RPATHDIR = @executable_path/../Frameworks

instead of specifying the linker flag manually, but the idea is the same.

These are basic aspects of OS X development which Qt doesn't add anything special to, and so the deployment process for Qt 5 frameworks is identical to the deployment process for "any other OS X framework".

Basically, make sure your app has @executable_path/../Frameworks in its rpath list, and don't touch the Qt frameworks or the install names that get linked into your binary. If you are ever using install_name_tool to post-process your binary, you are probably doing something wrong, or your dependencies are doing something wrong (for example, Qt < 5.5).

I agree we should update the "OS X Deployment" documentation (and possibly link to Apple documentation on dyld and rpaths, and how they work).

> Obviously I am talking about deploying a Qt application and the Qt Frameworks into a DMG package, to be run on a machine that doesn't have Qt installed.
> 
> I am using OSX 10.10.5 and XCode 7, if this can add any value.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


In closing, always use @rpath-based install names, and never use install_name_tool.
-- 
Jake Petroules - jake.petroules at petroules.com

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


More information about the Development mailing list