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

[Thiago Macieira]

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.

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

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?

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

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?

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

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