Hello,
Ricardo Wurmus <rekado@elephly.net> skribis:
Toggle quote (17 lines)
>> Since commit 2b0c755d195c79bfc95cdbe802e1e2dea1adb7a2 in August 2018,>> our 'gnome-shell' executable has been wrapped by a script that sets>> LD_LIBRARY_PATH.>>>> One consequence of this, which I just noticed, is that if 'gnome-shell'>> is based on 'core-updates' (or in my case, 'core-updates-next'), many>> programs based on 'master' will fail to run within the resulting GNOME>> session.> […]>> I was unable to easily find an existing bug report tracking this issue,>> so I created this one.>> There was no bug report about this, so thanks for reporting it. I once> brought this issue up on the mailing list here:>> https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00372.html
Looking at this bit in the ‘gnome-shell’ definition:
Toggle snippet (12 lines)
(wrap-program (string-append out "/bin/gnome-shell") `("GI_TYPELIB_PATH" ":" prefix (,gi-typelib-path)) ;; FIXME: gnome-shell loads these libraries with unqualified ;; names only, so they need to be on LD_LIBRARY_PATH. The ;; alternative might be to patch gnome-shell. `("LD_LIBRARY_PATH" ":" prefix ,(map (lambda (pkg) (string-append (assoc-ref inputs pkg) "/lib")) '("gdk-pixbuf" "gnome-bluetooth" "librsvg" "libgweather"))))
I checked in Gjs etc. how those imports (e.g., “imports.gi.Rsvg” inJavascript) are turned into a dlopen. AIUI, this is done bygobject-introspection based on info found in .gir files.
In Guix, .gir files contain absolute file names of share libraries. Atrun-time, ‘gobject-introspection-absolute-shlib-path.patch’ ensures thatdlopen is passed absolute file names.
So, IIUC, “imports.gi.Rsvg” should lead to dlopen by absolute file name,in which case setting LD_LIBRARY_PATH is useless.
However, does anyone know about we can test whether removing theLD_LIBRARY_PATH wrapping above breaks something?
Thanks,Ludo’.