diff options
author | Alexandru Croitor <alexandru.croitor@qt.io> | 2020-04-15 18:48:26 +0200 |
---|---|---|
committer | Alexandru Croitor <alexandru.croitor@qt.io> | 2020-04-17 15:59:25 +0200 |
commit | 67ee92f4d898ee76c40b7efd8e69782a6a4a3754 (patch) | |
tree | 57c4934656c2f15a59a70cd53aa0f73fd4fd838d /cmake/QtAutoDetect.cmake | |
parent | e6d880e511db7f12bda1f8ee599246d30b7ebf1b (diff) |
CMake: Handle automatic rpath embedding correctly
Instead of using CMAKE_INSTALL_RPATH to embed an absolute path
to prefix/libdir into all targets, use the more sophisticated aproach
that qmake does.
For certain targets (modules, plugins, tools) use relative rpaths.
Otherwise embed absolute paths (examples, regular binaries).
Installed tests currently have no rpaths.
On certain platforms rpaths are not used (Windows, Android,
iOS / uikit).
Frameworks, app bundles and shallow bundles should also be handled
correctly.
Additional rpaths can be provided via QT_EXTRA_RPATHS variable
(similar to the -R option that configure takes).
Automatic embedding can be disabled either via QT_FEATURE_rpath=OFF
or QT_DISABLE_RPATH=ON.
Note that installed examples are not relocatable at the moment (due
to always having an absolute path rpath), so this is a missing feature
compared to qmake. This is due to missing information on where
examples will be installed, so a relative rpath can not be computed.
By default a Qt installation is relocatable, so there is no need to
pass -DQT_EXTRA_RPATHS=. like Coin used to do with qmake e.g. -R .
Relative rpaths will have the appropriate 'relative base' prefixed
to them (e.g $ORIGIN on linux and @loader_path on darwin platforms).
There is currently no support for other platforms that might have a
different 'relative base' than the ones mentioned above.
Any extra rpaths are saved to BuildInternalsExtra which are re-used
when building other repositories.
configurejson2cmake modified to include correct conditions for the
rpath feature.
It's very likely that we will need a new qt_add_internal_app()
function for gui apps that are to be installed to prefix/bin.
For example for Assistant from qttools. Currently such apps
use qt_add_executable().
The distinction is necessary to make sure that relative rpaths are
embedded into apps, but not executables (which tests are part of).
Amends e835a6853b9c0fb7af32798ed8965de3adf0e15b
Task-number: QTBUG-83497
Change-Id: I3510f63c0a59489741116cc8ec3ef6a0a7704f25
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Diffstat (limited to 'cmake/QtAutoDetect.cmake')
-rw-r--r-- | cmake/QtAutoDetect.cmake | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/cmake/QtAutoDetect.cmake b/cmake/QtAutoDetect.cmake index d5d93007ba..dd5d8a6bd6 100644 --- a/cmake/QtAutoDetect.cmake +++ b/cmake/QtAutoDetect.cmake @@ -153,6 +153,11 @@ function(qt_auto_detect_ios) message(FATAL_ERROR "Building Qt for ${CMAKE_SYSTEM_NAME} as shared libraries is not supported.") endif() + + # Disable qt rpaths for iOS, just like mkspecs/common/uikit.conf does, due to those + # bundles not being able to use paths outside the app bundle. Not sure this is strictly + # needed though. + set(QT_DISABLE_RPATH "OFF" CACHE BOOL "Disable automatic Qt rpath handling." FORCE) endif() endfunction() |