gnome-shell: LD_LIBRARY_PATH setting propagates to entire session

OpenSubmitted by Mark H Weaver.
Details
3 participants
  • Ludovic Courtès
  • Mark H Weaver
  • Ricardo Wurmus
Owner
unassigned
Severity
important
M
M
Mark H Weaver wrote on 20 Aug 2019 21:21
Download
(address . bug-guix@gnu.org)
87zhk3tzfn.fsf@netris.org
Download
Since commit 2b0c755d195c79bfc95cdbe802e1e2dea1adb7a2 in August 2018,our 'gnome-shell' executable has been wrapped by a script that setsLD_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'), manyprograms based on 'master' will fail to run within the resulting GNOMEsession.
I ran into this issue because I recently rebuilt my Guix system based on'core-updates-next' and booted into it, although it will take more timeto finish rebuilding my user profile. Many programs, including Emacsand Nautilus, fail to launch. A workaround is to launch a terminal,unset LD_LIBRARY_PATH within the resulting shell, and then manually runthe other programs from within that shell. (Since then, I've built atrimmed-down version of my profile based on 'core-updates-next'.)
I was unable to easily find an existing bug report tracking this issue,so I created this one.
Mark
R
R
Ricardo Wurmus wrote on 20 Aug 2019 21:38
Download
(address . mhw@netris.org)(address . 37123@debbugs.gnu.org)
87sgpvlj8t.fsf@elephly.net
Download
Hi Mark,
Toggle quote (8 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.
[…]
Toggle quote (3 lines)> 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 oncebrought this issue up on the mailing list here:
https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00372.html
--Ricardo
L
L
Ludovic Courtès wrote on 24 Aug 2019 15:17
Download
control message for bug #37123
(address . control@debbugs.gnu.org)
87o90eya6q.fsf@gnu.org
Download
severity 37123 importantquit
L
L
Ludovic Courtès wrote on 13 Nov 2019 23:02
Download
Re: bug#37123: gnome-shell: LD_LIBRARY_PATH setting propagates to entire session
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87pnhvmo37.fsf@gnu.org
Download
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’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 37123@debbugs.gnu.org