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

Jake Petroules jake.petroules at petroules.com
Tue Sep 29 17:32:21 CEST 2015


> On Sep 29, 2015, at 2:11 AM, Ziller Eike <Eike.Ziller at theqtcompany.com> wrote:
> 
> 
>> 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:
>>> 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.
> 
> Actually you should use install_name_tool to remove the absolute rpath to the Qt libs on the build machine from your application binaries.

If you set QMAKE_RPATHDIR to some value (including an empty value), then qmake won't add the absolute path in the first place. Your build system must not force things into your binary that you don't necessarily want.

>> -- 
>> Jake Petroules - jake.petroules at petroules.com
>> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> -- 
> 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
> 

-- 
Jake Petroules - jake.petroules at petroules.com

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


More information about the Development mailing list