> 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 :)
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. - 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
