[KDE/Mac] Review Request 125614: Enable normal rpath handling on Mac
Christoph Cullmann
cullmann at kde.org
Mon Oct 12 21:48:10 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.
> 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.
- 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/20151012/7ae2cced/attachment.html>
More information about the kde-mac
mailing list