-
Friedrich W. H. Kossebau authored
Summary: When installing marble to a non-standard system directory the executable loader needs to be informed about the location of the marble libraries. Until now for marble executables this needs to be done via the env var LD_LIBRARY_PATH, which has the disadvantage of needing to be done as explicit separate step and also affects other executables which see this env var. Instead the custom locations of linked libraries can be tagged within the executable, via the RPATH (or RUNPATH) entries, which then is automatically available and also only valid for the given executable. Libmarblewidget only works with data & plugins in installation folders. So when running executables from the build dir (apps, tools, tests) linked to libraries from the build dir, for one things might not work due to not yet installed data/plugins. Or there are API/ABI-related changes done but without reinstallation, so installed plugins and libraries in the build dir are incompatible and will fail with strange behaviour. To protect against that some more when linking the executables in the build dir the RPATH can be set already to the installation location only, so the versions of the libraries in the build dir will not be seen and at least libraries and plugins are consistent. More info e.g. here: https://cmake.org/Wiki/CMake_RPATH_handling http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html Reviewers: rahn, shentey, nienhueser, #marble Reviewed By: nienhueser, #marble Differential Revision: https://phabricator.kde.org/D3358
c816a2bc