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

[Ziller Eike]

> On Sep 29, 2015, at 10:27, Jake Petroules <jake.petroules at petroules.com> wrote:
> 
> 
>> 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.

It would help to let qmake automatically add rpath @executable_path/../Frameworks to application binaries.

On the other hand this would lead to people deploying their applications with the _absolute_ rpath to the Qt libs as on the build machine still present (because it works). I think we should avoid that.

Br, Eike

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