On 2014-08-08, at 11:20 AM, Thiago Macieira <[email protected]> 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,@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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
