From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hartmut Goebel Subject: Re: 07/09: gnu: kinit: Use LIBRARY_PATH to search for dynamically loaded libs. Date: Mon, 7 Jan 2019 14:22:19 +0100 Message-ID: <258e37be-8fbc-efd8-d900-abb7193bf69c@crazy-compilers.com> References: <20190104091143.6774.92096@vcs0.savannah.gnu.org> <20190104091145.4226F209C7@vcs0.savannah.gnu.org> <87lg3z5gj2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:39125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ggUrV-0001ST-1K for guix-devel@gnu.org; Mon, 07 Jan 2019 08:22:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ggUrT-0003Eu-TO for guix-devel@gnu.org; Mon, 07 Jan 2019 08:22:36 -0500 In-Reply-To: <87lg3z5gj2.fsf@gnu.org> Content-Language: en-US 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" To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= , guix-devel@gnu.org Hallo Ludo, Am 05.01.19 um 15:24 schrieb Ludovic Court=C3=A8s: >> ++ // Try to load the library relative to the active pr= ofiles. >> ++ QByteArrayList profiles =3D qgetenv("LIBRARY_PATH").= split(':'); >> ++ for (const QByteArray &profile: profiles) { >> ++ if (!profile.isEmpty()) { >> ++ l.setFileName(QFile::decodeName(profile) + Q= StringLiteral("/") + libpath); >> ++ if (l.load()) break; >> ++ } > I find this use of LIBRARY_PATH questionable: it=E2=80=99s the variable= normally > used by the compiler driver (gcc) at link time, not by the loader > (ld.so). IOW, it=E2=80=99s really a compile-time variable, and one tha= t has > nothing to do with Qt or KDE. > > What about using a different variable for this purpose? It could be > KDE_PLUGIN_PATH or something like this, and we could add it to > =E2=80=98native-search-paths=E2=80=99 of kinit.=20 Thanks for discovering and pointing this out. Looks like I did a mistake here. Oh, and when rethinking, I made even more mistakes here. Indeed I was thinking about a native-search-path, too, but abandoned this since I thought, LIBRARY_PATH would already be there. The original KDE code searches for the shared lib in CMAKE_INSTALL_PREFIX/LIB_INSTALL_DIR/ only. Nixos loops over NIX_PROFILES, looking into $profile/lib/, which would ma= tch =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = (search-path-specification =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 (variable "KDEINIT5_LIBRARY_PATH") =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 (files '("lib/"))) which would make all packages including a shared lib to be listed in the environment variable. (This is why I came to the wrong idea of using the already existing LIBRARY_PATH.) I'm not confident this is a good idea. One possible solution would be: Since the name to be loaded will be prefixed by "/libkdeinit5_" (see some lines above [1]), we could change this into "/libkdeinit5/" which then could become KDEINIT5_LIBRARY_PATH. This of course has the draw back of a larger patch and that *all* packages providing plugins for kinit need to be patched, too. WDYT? Any other=C2=A0 idea? > We could also avoid the =E2=80=9C+ libpath=E2=80=9D bit I suppose. The =E2=80=9C+ libpath=E2=80=9D bit can not be avoided, since this is the= actual name to be loaded. [1] https://cgit.kde.org/kinit.git/tree/src/kdeinit/kinit.cpp?h=3Dv5.53.0= #n625 [2] https://github.com/NixOS/nixpkgs/blob/18.09/pkgs/development/libraries/kd= e-frameworks/kinit/kinit-libpath.patch --=20 Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |