[Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)

[Jake Petroules]

On 2014-08-08, at 11:20 AM, Thiago Macieira <thiago.macieira at intel.com> wrote:

> On Thursday 07 August 2014 17:11:49 Jake Petroules wrote:
>>>> Next steps:
>>>> (1) changes to macdeployqt (removing absolute rpath & rewrite)
>>>> (2) remove rewriting in installer-framework
>>> 
>>> Please don't remove the rewriting of qmake itself.
>> 
>> Please elaborate? qmake is an executable and doesn't have a soname, there's
>> nothing to rewrite.
>> 
>> If you're referring to its run path search path, I see no reason it should
>> be an absolute path rather than simply [@executable_path/../lib]. That's
>> not going to make any difference other than stubbornly making the SDK
>> non-relocatable, which is what we're trying to achieve here.
>> 
>> If you're referring to paths embedded in the binary as strings... well,
>> can't really rewrite that (yet) anyways.
> 
> I'm referring to the paths embedded in the qmake binary as strings, which it 
> uses to provide the output of "qmake -query" and to find the mkspecs and the 
> default options to the Makefiles.

In qmake, can you explain why we can't use: QCoreApplication::applicationFilePath() + "/../bin", etc.?

>> Roughly:
>> 1. QtCore linker flags have -install_name
>> @rpath/QtCore.framework/Versions/5/QtCore when the SDK is built 
>> 2. User
>> application links to QtCore with -F/Developer/Qt/Library/Frameworks/
>> -framework QtCore 
>> 3. Linker pulls in
>> @rpath/QtCore.framework/Versions/5/QtCore from the QtCore executable,
>> writes it into user application 
>> 4. User application adds
>> -Wl,-rpath, at executable_path/../Frameworks to linker flags (can have
>> multiple paths) 
>> 5. Dependent frameworks (Qt, Sparkle, Growl, etc.) copied
>> into application bundle 
>> 6. Load time: for each library loaded by
>> application, dyld substitutes @rpath for each path added in step (4) until
>> a match is found
> 
> I'm seeing a disagreement here between your answer and Adam's.

We're splitting these changes into two "phases":

Phase I: Internal changes only
Phase II: User-visible workflow changes

I was speaking in terms of Phase II, Adam's answer is specific to Phase I.

> The point is that QtCore is not in a path searched by default by dyld. The 
> linker found it because of -F, but how does dyld find it?

It is. ;) Because QtCore in current Qt SDKs has an absolute soname ($QT_INSTALL_LIBS/QtCore.framework/Versions/5/QtCore), that path gets burned into the executable that links to it, just as @rpath/QtCore.framework/Versions/5/QtCore would if it were using rpath. Because we currently use absolute sonames... that's how the libraries are found.

> Your answer does not explain how (6) finds /User/tjmaciei/Qt/whatever which is 
> where the SDK installed the library..

Well, I explained the process specifically for when the search path was using @rpath. If it was absolute, relative, or used a different placeholder like @executable_path, @loader_path, or @load_path, it would be processed according to the rules for those. See above.

> Adam's answer suggests that this path is temporarily written on the executable 
> during linking, but macdeployqt will remove it at the same time as it copies 
> the QtCore.framework bundle to inside the application bundle.
> 
> Which is it?

Currently, Adam's answer is correct and will continue to be correct after Phase I is completed. My answer will be correct after Phase II is completed.

>>> Also, how does QtCore find the plugins on behalf of every library? For
>>> example, when QtGui requests the cocoa platform plugin, what is the
>>> search logic?
>> This is why plugins should be bundled INSIDE the frameworks they "belong"
>> to. This area does need work. Generally, I'd think the search path would
>> start with the current bundle's plugin path, then the main bundle's plugin
>> path. For dylibs build of Qt this should work too.
> 
> Note that I said "how does QtCore find QtGui's plugin". If the cocoa plugin is 
> somewhere inside QtGui.framework (which got deployed inside the application), 
> how does QtCore.framework find it there?
> 
> If this is not implemented yet -- and it doesn't seem it is -- please explain 
> what the long-term, end-result is meant to be.

This should be answered by my above comments. You're correct it's not implemented yet; some of this stuff (especially plugins) needs additional thought.

> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation