> On Sep 29, 2015, at 10:27, Jake Petroules <[email protected]> > wrote: > > >> On Sep 28, 2015, at 2:40 PM, Thiago Macieira <[email protected]> >> 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,@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 > [email protected] > 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
