[Development] Qt 5.5.0 build issues on OS X : rpath
Eike.Ziller at theqtcompany.com
Tue Sep 29 11:11:51 CEST 2015
> On Sep 29, 2015, at 10:16, Jake Petroules <jake.petroules at petroules.com> wrote:
>> 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:
>> 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
>> 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
> In closing, always use @rpath-based install names, and never use install_name_tool.
Actually you should use install_name_tool to remove the absolute rpath to the Qt libs on the build machine from your application binaries.
> Jake Petroules - jake.petroules at petroules.com
> Development mailing list
> Development at qt-project.org
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
More information about the Development