<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 29, 2015, at 2:35 AM, Massimo Callegari <<a href="mailto:massimocallegari@yahoo.it" class="">massimocallegari@yahoo.it</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote><br class=""><br class="">Again, the matter is simple: what was working from Qt 4.8 up to Qt 5.4.2 is not working anymore with Qt 5.5.x. At least for me.<br class=""></div></div></blockquote><div><br class=""></div><div>Because it was previously using a configuration that was extremely uncommon in real world Mac development. Now it's fixed and you are required to adapt your project in accordance.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Since Qt 4.8 and up to Qt 5.4.2 I was using the install_name_tool procedure as described here:<br class=""><a href="http://doc.qt.io/qt-5/osx-deployment.html" class="">http://doc.qt.io/qt-5/osx-deployment.html</a><br class="">With prebuilt Qt 5.5.x clang64, QtFrameworks don't use absolute paths anymore, but instead they use @rpath, so calling something like this<br class=""><br class="">install_name_tool -change @rpath/QtCore.framework/Versions/5/QtCore<br class="">@executable_path/../Frameworks/QtCore.framework/Versions/5/QtCore<br class="">myapp.app/Contents/MacOs/myapp<br class="">appears not to be working. (and not needed anymore)<br class=""><br class=""></blockquote></blockquote><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote><br class=""><br class="">But it's what Trolltech/Nokia/Digia/QtCompany suggest to do !<br class="">Here again: <a href="http://doc.qt.io/qt-5/osx-deployment.html" class="">http://doc.qt.io/qt-5/osx-deployment.html</a><br class=""></div></div></blockquote><div><br class=""></div><div>As I said, the documentation needs to be updated. I'll update it so that it provides more information and better corresponds with what I said earlier.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Deploying an OSX app is not only packing an application binary + the Qt libraries.<br class=""><br class="">My project has a plethora of other libraries coming from MacPorts and a number of QtPlugins loaded at runtime.<br class=""><br class="">So, I HAVE to perform install_name_tool on those ! (until MacPorts decide to go the rpath way as well...which I guess will make a lot of people upset)<br class=""></div></div></blockquote><div><br class=""></div><div>That's the "broken dependency" case. Why MacPorts has a no-rpath policy on a platform where you copy the actual libraries into your product, I have no idea. Maybe try Homebrew, they tend to be more up-to-date anyways.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Anyway, see with your eyes. There are a lot of conditions to build on Qt4, QML, etc, but it should give you the idea of "my use case":<br class=""><a href="https://github.com/mcallegari/qlcplus/tree/master/macx" class="">https://github.com/mcallegari/qlcplus/tree/master/macx</a><br class=""><br class="">Start from macx.pro<br class=""><br class="">If you want to see what's inside my DMGs, download from here:<br class="">http://sourceforge.net/projects/qlcplus/files/4.9.1/<br class=""></div></div></blockquote></div><div class=""><br class=""></div>You can easily have a build setup that works for all Qt versions from 4.8 through 5.5. Simply use install_name_tool to transform dynamic library install names to @rpath-based ones as always (if they are already in the latter form, the commands will do nothing), and add @loader_path/../Frameworks to your own binaries -- simple as that. It'll work with 4.8, 5.4, 5.5...<br class=""><div apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">-- <br class="">Jake Petroules - jake.petroules at <a href="http://petroules.com" class="">petroules.com</a><br class=""></div>

</div>
<br class=""></body></html>