> On Sep 29, 2015, at 2:11 AM, Ziller Eike <[email protected]> wrote: > > >> On Sep 29, 2015, at 10:16, Jake Petroules <[email protected]> >> wrote: >> >> >>> On Sep 28, 2015, at 2:30 PM, Massimo Callegari <[email protected]> >>> wrote: >>> >>> On Monday 28 September 2015 19:09:11 Massimo Callegari wrote: >>>>> But please guys, when introducing such an important change, you are >>>>> warmthly >>>>> invited to mention it in a visible place. >>> >>>> It's in the changelog. >>> >>>> But I confess the line you're referring to does not indicate that anything >>>> should break. Qt being build with rpath should enable more, but not remove >>>> functionality that existed. >>> >>>> Can you explain what broke for you? >> >> From what I can see, nothing is "broken" for him in the sense he is not >> limited from doing anything he was previously able to do. >> >>> 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) >> >> Do not do that. You *want* the @rpath version; using anything but >> rpath-based install names on Apple platforms is an obscure edge case. If you >> think you need that, you almost certainly don't. >> >> We need to start code-signing our official releases to stop people from >> doing this. :) >> >>> 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 >>> >>> I might got it wrong, but at least this is what I got and how I made it >>> work back again. >>> If there is a proper and official way to deploy any Qt5 version in a unique >>> way, please point me to the right documentation. >> >> That is the right way and always has been. Ideally you should use: >> >> QMAKE_RPATHDIR = @executable_path/../Frameworks >> >> instead of specifying the linker flag manually, but the idea is the same. >> >> These are basic aspects of OS X development which Qt doesn't add anything >> special to, and so the deployment process for Qt 5 frameworks is identical >> to the deployment process for "any other OS X framework". >> >> Basically, make sure your app has @executable_path/../Frameworks in its >> rpath list, and don't touch the Qt frameworks or the install names that get >> linked into your binary. If you are ever using install_name_tool to >> post-process your binary, you are probably doing something wrong, or your >> dependencies are doing something wrong (for example, Qt < 5.5). >> >> I agree we should update the "OS X Deployment" documentation (and possibly >> link to Apple documentation on dyld and rpaths, and how they work). >> >>> Obviously I am talking about deploying a Qt application and the Qt >>> Frameworks into a DMG package, to be run on a machine that doesn't have Qt >>> installed. >>> >>> I am using OSX 10.10.5 and XCode 7, if this can add any value. >>> _______________________________________________ >>> Development mailing list >>> [email protected] >>> http://lists.qt-project.org/mailman/listinfo/development >> >> In closing, always use @rpath-based install names, and never use >> install_name_tool. > > Actually you should use install_name_tool to remove the absolute rpath to the > Qt libs on the build machine from your application binaries.
If you set QMAKE_RPATHDIR to some value (including an empty value), then qmake won't add the absolute path in the first place. Your build system must not force things into your binary that you don't necessarily want. >> -- >> 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 > -- Jake Petroules - jake.petroules at petroules.com
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
