Andreas Enge <andr...@enge.fr> skribis: > On Wed, Nov 05, 2014 at 10:18:18PM +0100, Andreas Enge wrote: >> It definitely sounds like a good idea. We could add the rpath linker flags >> for Qt and for KDE via -DCMAKE_SHARED_LINKER_FLAGS and >> -DCMAKE_EXE_LINKER_FLAGS to the kde build system. I would like to give >> it a try. > > It works! I am attaching the updated kdelibs patch (still not finished, > just for your information; but I took Ludovic's suggestions into account).
Cool! LGTM. > So for the kde build system, we could add such lines to code the Qt and KDE > libraries into the rpath. Different submodules (at least kdegames) > also come with their own additional libraries. Anyway, I had the intention > of creating separate guile modules for them to keep a manageable number of > packages per module. So one could imagine a KDE build system, and a local > extended variant in each module inheriting from it. > > So is this a solution we should implement, or does anyone have a better idea > or an argument why this would be bad? Apologies if this was already mentioned, but why don’t -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE and -DCMAKE_INSTALL_RPATH=$out/lib (in cmake-build-system.scm) lead to binaries with a RUNPATH? As Eric said, this should produce binaries with an appropriate RUNPATH, no? Or does it only take care of setting the RUNPATH to $out/lib? To me, passing -Wl,-rpath would be a workaround for a package-specific defect. The ideal solution would be to have cmake-build-system DTRT. Thanks, Ludo’.
