[Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)

Adam Strzelecki ono at java.pl
Mon Aug 4 21:38:27 CEST 2014


> Before you do that, can you write up a proposal on what you want to accomplish and how to get there?

WHAT I WANT TO ACOMPLISH

(1) Remove need to rewrite Qt libraries (frameworks) headers during install and during macdeployqt
(2) This makes possible to check whether libraries came from official SDK (i.e. md5 sums)
(3) Won't invalidate frameworks signatures when changing their binary contents
(4) Make SDK relocable, so it can be moved around w/o need to reinstall, also making drag&drop SDK installer possible for Mac

HOW TO GET THERE

Core changes to make things working:

(1) [qtbase/qmake] Add `QMAKE_INSTALL_NAME_PREFIX` variable which defaults to `@rpath` when using `lib_bundle` configuration.
(2) [qtbase/qmake/UnixMakefile,PBX] When `QMAKE_INSTALL_NAME_PREFIX` is set and `absolute_library_soname` is not active prepend $QMAKE_INSTALL_NAME_PREFIX/ to $soname.
(3) [qtbase/qmake] Set `QMAKE_RPATH_DIR` to relative to executable path $QT_INSTALL_LIBS by default for all Qt Mac projects, additionally `@executable_path/../Frameworks` to `app_bundle` projects **Jake would argue but please see reasoning at the very bottom**

Build Qt SDK with @rpath

(4) [qtbase] Remove `absolute_library_soname` from Mac build, so all Qt frameworks are built by default with @rpath/ install id.
(5) [installer-framework] Remove rewriting install ids as no longer necessary
(6) [qtsdk] Remove padding folder

Make changes to macqtdeploy

(7) [qttools/macdeployqt] Remove rewriting Qt frameworks install ids after copying them to the bundle
(8) [qttools/macdeployqt] Remove rewriting Qt frameworks paths in executable (they will be already @rpath/...)
(9) [qttools/macdeployqt] Add `install_name_tool -delete_rpath $QT_INSTALL_LIBS SomeApp.app/Contents/MacOS/SomeApp`

That's it. No changes needed to Qt Creator, existing Qt projects, etc. etc.

Further changes to drop putting any absolute paths during build, and copy frameworks to build (as Jake proposed) should be next step. As I said first I want to introduce @rpath but keep current workflow untouched. Then we can discuss further workflow improvements.

Regards,
-- 
Adam Strzelecki




More information about the Development mailing list