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

[Jake Petroules]

On 2014-08-07, at 10:22 AM, Thiago Macieira <thiago.macieira at intel.com> wrote:

> On Thursday 07 August 2014 14:55:06 Adam Strzelecki wrote:
>> The changes for qtbase are there:
>> 
>>        https://codereview.qt-project.org/91669
>>        https://codereview.qt-project.org/91670
>>        https://codereview.qt-project.org/91671
>>        https://codereview.qt-project.org/91672
>>        https://codereview.qt-project.org/91673
>>        https://codereview.qt-project.org/91674
>>        https://codereview.qt-project.org/91675
>>        https://codereview.qt-project.org/91676
>> 
>> This makes Qt SDK build:
>> (1) completely relocatable once installed
>> (2) all tools and examples refer frameworks relatively
>> (3) there is no hardcoded SDK in any framework or tool (except qmake which
>> keep SDK prefix)
>> 
>> 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.

>> FYI since installer rewrites absolute paths in frameworks, and there a none
>> now this shouldn't have impact on Mac SDK installer itself.
> 
> Nice work!
> 
> How does a launched application find the Qt frameworks that were installed by 
> the SDK? And how do those frameworks find the plugins?
> 
> I mean, if I compile an application, the path to the frameworks is set with 
> the -F switch, which qmake knows as it's hardcoded. But how does the dyld know 
> the path when the application is launched? Doesn't DYLD_LIBRARY_PATH and 
> DYLD_FRAMEWORK_PATH need to be set? Is the Creator modification one of those 
> changes?

-F is merely the frameworks equivalent of -L and -I, it has no impact on dyld behavior.

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

Indeed, the path list from step (4) can be augmented with env vars DYLD_LIBRARY_PATH/DYLD_FRAMEWORK_PATH (which are searched before the executable's own search list). An IDE could do this (and Xcode does, Qt Creator should as well), but step (5) should be performed regardless, controlled by a qmake variable as Ossi suggested. This makes things relatively configurable so users can work any way they like.

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

As far as Qt when NOT bundled into the target app goes... how about we determine where QtCore was loaded from on disk and look for plugins somewhere relative to that? And of course, override all this using qt.conf (or fallback, whatever).

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