From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] gnu: kde: Add kdelibs. Date: Thu, 06 Nov 2014 12:46:21 +0100 Message-ID: <871tpglfg2.fsf@gnu.org> References: <87tx2d2ykt.fsf@gnu.org> <87ioitwfxf.fsf@gmail.com> <20141105211818.GA1181@debian> <20141105232032.GA24522@debian> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmLWI-0007jM-LT for guix-devel@gnu.org; Thu, 06 Nov 2014 06:46:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmLWC-00030U-LB for guix-devel@gnu.org; Thu, 06 Nov 2014 06:46:30 -0500 Received: from hera.aquilenet.fr ([2a01:474::1]:48860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmLWC-0002zn-DN for guix-devel@gnu.org; Thu, 06 Nov 2014 06:46:24 -0500 In-Reply-To: <20141105232032.GA24522@debian> (Andreas Enge's message of "Thu, 6 Nov 2014 00:20:32 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andreas Enge Cc: Guix-devel , Federico Beffa Andreas Enge 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 fla= gs >> 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 K= DE > 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 i= dea > or an argument why this would be bad? Apologies if this was already mentioned, but why don=E2=80=99t -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=3DTRUE and -DCMAKE_INSTALL_RPATH=3D$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=E2=80=99.