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-frameworks-devel/attachments/20151012/7ae2cced/attachment.html>


More information about the Kde-frameworks-devel mailing list