> 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
