[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) |
Hello,
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
>> (ld.so). 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
> CMAKE_INSTALL_PREFIX/LIB_INSTALL_DIR/ only.
>
> 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
decide.
As downstreams, the most reasonable option is to honor the
KDEINIT5_LIBRARY_PATH as you defined it above IMO.
Thanks,
Ludo’.