[KDE/Mac] Review Request 125614: Enable normal rpath handling on Mac
Christoph Cullmann
cullmann at kde.org
Tue Oct 13 08:10:50 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.
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.
- 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-mac/attachments/20151013/b3122f8f/attachment-0001.html>
More information about the kde-mac
mailing list