[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 07/09: gnu: kinit: Use LIBRARY_PATH to search for dynamically loaded

From: Ludovic Courtès
Subject: Re: 07/09: gnu: kinit: Use LIBRARY_PATH to search for dynamically loaded libs.
Date: Tue, 08 Jan 2019 18:16:00 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)


Hartmut Goebel <address@hidden> skribis:

> Am 05.01.19 um 15:24 schrieb Ludovic Courtès:
>>> ++                // Try to load the library relative to the active 
>>> profiles.
>>> ++                QByteArrayList profiles = 
>>> qgetenv("LIBRARY_PATH").split(':');
>>> ++                for (const QByteArray &profile: profiles) {
>>> ++                    if (!profile.isEmpty()) {
>>> ++                        l.setFileName(QFile::decodeName(profile) + 
>>> QStringLiteral("/") + libpath);
>>> ++                        if (l.load()) break;
>>> ++                    }
>> I find this use of LIBRARY_PATH questionable: it’s the variable normally
>> used by the compiler driver (gcc) at link time, not by the loader
>> (  IOW, it’s really a compile-time variable, and one that 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
>> ‘native-search-paths’ of kinit. 
> 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
> Nixos loops over NIX_PROFILES, looking into $profile/lib/, which would match
>              (search-path-specification
>               (variable "KDEINIT5_LIBRARY_PATH")
>               (files '("lib/")))
> which would make all packages including a shared lib to be listed in the
> environment variable.

Well, only the lib/ directories themselves would be listed, which is
probably fine.

(It would of course be nicer if KDE would instead store these plugins in
lib/kdeinit or something.)

> 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.

I think it’s a good idea, but this is something that upstream should

As downstreams, the most reasonable option is to honor the
KDEINIT5_LIBRARY_PATH as you defined it above IMO.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]