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

[Jake Petroules]

> On Sep 28, 2015, at 2:40 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Monday 28 September 2015 21:30:33 Massimo Callegari wrote:
>>> Can you explain what broke for you?
>> 
>> 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)
> 
> Does the tool report an error now? Is that what broke?

With `install_name_tool -change A B C`, if the dependent shared library install name A does not exist in the Mach-O file C, it's a no-op and the tool returns 0.

> 
>> 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
> 
> And if you don't do that do your executable, the loading fails?

Correct. But you're supposed to add that.

> What if we add an extra rpath to Qt libs as @executable_path/../Frameworks? 
> Would this make loading work?

No. The rpath list is embedded in the loading binary A, and specifies where the loading binary A looks for its dependents. If a dependent shared library install name B contains the placeholder '@rpath', that placeholder is substituted for each rpath in loading binary A's rpath list (recursively replacing other placeholders like @executable_path and @loader_path if present) until a match is found.

This would only help QtGui find QtCore, for example. The loading binary A still has to find a Qt library in the first place.

Please refer to https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html

> Jake, Morten: as a stop-gap, is there a configure-time switch to revert to the 
> old behaviour? This change seems to be too much for a patch release. It should 
> be left for 5.6.0 only.

./configure -no-rpath -- that switch has been there since the beginning of time. I don't remember if that also sets CONFIG+=absolute_library_soname by default.

It's also useless, because you virtually never want that (unless you are MacPorts, Debian, etc.), and the changes required on the application side are both less intrusive and easier to deal with anyways, in addition to being the correct workflow on Apple platforms and not breaking code signing.

> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 

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

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