Review Request 125614: Enable normal rpath handling on Mac
Christoph Cullmann
cullmann at kde.org
Tue Oct 13 11:36:09 UTC 2015
> On Oct. 12, 2015, 8:48 p.m., René J.V. Bertin wrote:
> > There is an issue with Qt 5.5.0's configure script, currently. From what I understand, the `-rpath` configure option works as intended, and gives relocatable framework bundles that are intended to be embedded in dependent app bundles.
> > Qt installs for a fixed, shared location should use `-no-rpath`, but the Qt5 build system currently doesn't add the `absolute_library_soname` option to the qmake config (see my "Qt 5.5.0 build issues on OS X : rpath" thread on Qt's development ML). The Qt 5.4.2 script did this correctly; I provide a patch that restores this with my `qt5-kde` port for MacPorts (https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde/files/patch-configure-find-opengl-and-correct-rpath.diff).
> >
> > (The absolute_library_soname config stores the full install name in the generated frameworks, without explicit use of `install_name_tool`).
>
> Christoph Cullmann wrote:
> Ok. But still, it would be nice to have the stuff working with a relocatable framework, too, and it does now with this patch. Will it hurt the other variant?
>
> René J.V. Bertin wrote:
> No, you just have to build Qt with `-rpath` (or modify the framework "rpaths" somehow; I think Qt's `macdeployqt` tool does that, and there's also a cmake recipe that has the same effect, at least with Qt 5.4).
>
> Looking at your patch, the question is rather: will "it" hurt the variant where Qt's frameworks are *not* meant to be embedded, but used from a fixed, shared location?
> (Semantics, but it's the app bundle that is relocatable; the Qt frameworks must be at a specific location inside the app bundle. Relocatable frameworks don't have path information in their install_name, and can be placed in any of `{/System/,/,~/}Library/Frameworks`.)
>
> Christoph Cullmann wrote:
> That was my question: Will it hurt the variant that is not meant to be embedded?
> If not, I would like to have this merged, to be able to compile against any variant of qt.
> With the above patch and my other patches still in the queue I am able to build a complete Kate with a stock qt and neither macports nor homebrew magic, just like:
>
> # errors fatal
> set -e
>
> # steps to build kate on make
>
> # install Qt 5.5.0
> # install CMake 3.3.2
>
> # set path to Qt 5.5.0 stuff
> export PATH=~/Qt5.5.0/5.5/clang_64/bin:/Applications/CMake.app/Contents/bin:$PATH
>
> # remember some dirs
> export PREFIX=`pwd`/usr
> export BUILD=`pwd`/build
> export SRC=`pwd`/src
>
> # install gettext
> mkdir -p src
> cd src
> curl http://ftp.gnu.org/pub/gnu/gettext/gettext-latest.tar.gz > gettext-latest.tar.gz
> tar -xvzf gettext-latest.tar.gz
> cd gettext-0.*
> ./configure --prefix=$PREFIX
> make install
> cd ..
> cd ..
>
> # build helper
> function build_framework
> { (
> # errors fatal
> set -e
>
> # framework
> FRAMEWORK=$1
>
> # create build dir
> mkdir -p $BUILD/$FRAMEWORK
>
> # go there
> cd $BUILD/$FRAMEWORK
>
> # cmake it
> cmake $SRC/$FRAMEWORK -DCMAKE_INSTALL_PREFIX:PATH=$PREFIX
>
> # make
> make -j2
>
> # install
> make install
> ) }
>
> # get stuff
> cd src
>
> git clone kde:extra-cmake-modules
> git clone kde:kconfig
> git clone kde:kguiaddons
> git clone kde:ki18n
> git clone kde:kitemviews
> git clone kde:sonnet
> git clone kde:kwindowsystem
> git clone kde:kwidgetsaddons
> git clone kde:kcompletion
> git clone kde:kdbusaddons
> git clone kde:karchive
> git clone kde:kcoreaddons
> git clone kde:kjobwidgets
> git clone kde:kcrash
> git clone kde:kservice
> git clone kde:kcodecs
> git clone kde:kauth
> git clone kde:kconfigwidgets
> git clone kde:kiconthemes
> git clone kde:ktextwidgets
> git clone kde:knotifications
> git clone kde:kglobalaccel
> git clone kde:kxmlgui
> git clone kde:kbookmarks
> git clone kde:solid
> git clone kde:kio
> git clone kde:kinit
> git clone kde:kparts
> git clone kde:ktexteditor
> git clone kde:kate
>
>
> cd ..
>
> # build stuff
>
> build_framework extra-cmake-modules
> build_framework kconfig
> build_framework kguiaddons
> build_framework ki18n
> build_framework kitemviews
> build_framework sonnet
> build_framework kwindowsystem
> build_framework kwidgetsaddons
> build_framework kcompletion
> build_framework kdbusaddons
> build_framework karchive
> build_framework kcoreaddons
> build_framework kjobwidgets
> build_framework kcrash
> build_framework kservice
> build_framework kcodecs
> build_framework kauth
> build_framework kconfigwidgets
> build_framework kiconthemes
> build_framework ktextwidgets
> build_framework knotifications
> build_framework kglobalaccel
> build_framework kxmlgui
> build_framework kbookmarks
> build_framework solid
> build_framework kio
> build_framework kinit
> build_framework kparts
> build_framework ktexteditor
> build_framework kate
>
> René J.V. Bertin wrote:
> I don't know how to answer that question, and you appear to be the only one who can test it.
> What does the cmake code do exactly? It keeps the original absolute path install_name (which would correspond to what Qt's `absolute_library_soname` config does), and then adds that same absolute path to the application's rpath list?
> I have no direct experience with using rpaths other than absolute ones and the special relative ones Apple provides (`@executable_path` and family), but that seems a more or less redundant situation that should not cause any issues as far as I can guess.
>
> But is that interpretation correct, does that cmake snippet being patched indeed store an absolute install_name? In that case you're not working on/with a variant that's embeddable, at least not in an app bundle that can be moved around freely.
>
> Christoph Cullmann wrote:
> > But is that interpretation correct, does that cmake snippet being patched indeed store an absolute install_name? In that case you're not working on/with a variant that's embeddable, at least not in an app bundle that can be moved around freely.
> No idea, I just keep that part in the cmake file to not break other stuff.
>
> Lets see if others have an idea, else I will commit that in the next days, as I see no evidence that it breaks things more than they are already broken at the moment.
>
> Ian Wadham wrote:
> I did dabble in library paths and rpaths on Apple OS X and CMake a year or so ago, but have forgotten all I learned. Googling "Apple OS X rpath" yields a mass of information.
>
> I got the impression that Apple OS X discourages this and prefers absolute paths of libraries to be wired into executables. Whether this is for security reasons or for backward compatibility of apps with older libraries I do not recall, but both goals are important in my opinion.
>
> Christoph, you might try going on the https://lists.macosforge.org/mailman/listinfo/macports-dev mailing list. There you will find a lot of expertise on OS X, Linux, BSD and Macports. The people there are very helpful with questions of the kind you pose. You might get good feedback there. Mention that you are a KDE Community release co-ordinator, BTW, and are seeking answers on how best to deploy KF5 and Frameworks for Apple OS X.
>
> Christoph Cullmann wrote:
> After all I have read so far, adding the additional rpaths won't hurt the setup MacPorts uses.
>
> René J.V. Bertin wrote:
> Possible, maybe even probable. Anyway, there is still going to be so much hacking from what I can see that this will hardly change anything.
>
> I'm still not sure you have achieved your goal if that was to make a location-independent app bundle with embedded frameworks. Did you try moving it (to a different machine, ideally, or after making one of the target Qt5/KF5 frameworks inaccessible)?
> I'm just thinking of the commit message here.
>
> Christoph Cullmann wrote:
> You are right, I think it is still not movable, therefore for the commit this is more like "make frameworks compilable with stock qt.io qt on mac". It is for sure not the final fix for all deployment issues.
> But I think it is a nice step forwards for non-macports/homebrew mac os builds, which IMHO are atm not possible at all with stock qt without this.
>
> René J.V. Bertin wrote:
> I'm not saying it isn't, but I'm not sure either if it's the best approach to pursue that goal without having first gotten KF5 applications to work (not just link) in a more familiar context. (I plan to have a look at that, but keep getting side-tracked.)
>
> BTW, when I did a Qt 5.5 build with the default `-rpath` setting, I ended up with frameworks that had an install name of `@rpath`. From what I understand, that means basically that they can be used either embedded or not, as long as the dependent application (or library?) has an rpath list that includes the frameworks' locations. Is that not what Qt's own installer provides? Last time I used that one was with Qt 5.4.1, which didn't use `@rpath` in custom builds (because OS X's rpath implementation was flaky, IIRC). Instead, frameworks were shipped with an insanely long bogus install_name, which was then edited to reflect the selected install location (and I mean without even using the install_name_tool). Crude, but effective :)
>
> Christoph Cullmann wrote:
> You compile frameworks on Mac, too, or? Could you try with my patch here if that still works for you? If yes, all is fine, else we can rethink this.
>
> René J.V. Bertin wrote:
> Heh, I'm talking about OS X style frameworks (.framework bundles), not KF5 frameworks. Unhappy choice of terminology there. I'm slowly getting to the point where I'll be trying my hand at building KF5, but not there yet (nor in the coming 2 weeks, I think).
>
> If you feel it should go in, do it, the change is simple enough to come back to it should the need arise. Maybe leave a comment in the cmake code so that is more likely we remember this change (or the original setting) if we run into rpath related issues down the road...
Then I will apply this now. Given the current state of frameworks 5 on mac, it can't hurt and it now compiles at least for me again.
- Christoph
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125614/#review86752
-----------------------------------------------------------
On Oct. 12, 2015, 6:46 p.m., Christoph Cullmann wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125614/
> -----------------------------------------------------------
>
> (Updated Oct. 12, 2015, 6:46 p.m.)
>
>
> Review request for KDE Software on Mac OS X, KDE Frameworks, Alex Merry, and Harald Fernengel.
>
>
> Repository: extra-cmake-modules
>
>
> Description
> -------
>
> Enable normal rpath handling on Mac, just in addition set the install name.
> Without this, with a plain qt installed via the qt mac installer, no program build runs, e.g. desktoptojson can't locate any Qt lib.
> With that all is fine and we have some reasonable rpaths:
>
> Load command 17
> cmd LC_RPATH
> cmdsize 48
> path /Users/cullmann/local/kf5/usr/lib (offset 12)
> Load command 18
> cmd LC_RPATH
> cmdsize 56
> path /Users/cullmann/Qt5.5.0/5.5/clang_64/lib (offset 12)
>
>
> Diffs
> -----
>
> kde-modules/KDECMakeSettings.cmake cefd6da
>
> Diff: https://git.reviewboard.kde.org/r/125614/diff/
>
>
> Testing
> -------
>
> Could build kservice with this patch again, as desktoptojson works.
>
>
> Thanks,
>
> Christoph Cullmann
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151013/a5c9f3c7/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list