gnome-shell: LD_LIBRARY_PATH setting propagates to entire session

  • Done
  • quality assurance status badge
Details
3 participants
  • Ludovic Courtès
  • Mark H Weaver
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Mark H Weaver
Severity
important
M
M
Mark H Weaver wrote on 20 Aug 2019 21:21
(address . bug-guix@gnu.org)
87zhk3tzfn.fsf@netris.org
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 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 time
to finish rebuilding my user profile. Many programs, including Emacs
and Nautilus, fail to launch. A workaround is to launch a terminal,
unset LD_LIBRARY_PATH within the resulting shell, and then manually run
the other programs from within that shell. (Since then, I've built a
trimmed-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
(address . mhw@netris.org)(address . 37123@debbugs.gnu.org)
87sgpvlj8t.fsf@elephly.net
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 once
brought this issue up on the mailing list here:


--
Ricardo
L
L
Ludovic Courtès wrote on 24 Aug 2019 15:17
control message for bug #37123
(address . control@debbugs.gnu.org)
87o90eya6q.fsf@gnu.org
severity 37123 important
quit
L
L
Ludovic Courtès wrote on 13 Nov 2019 23:02
Re: bug#37123: gnome-shell: LD_LIBRARY_PATH setting propagates to entire session
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87pnhvmo37.fsf@gnu.org
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” in
Javascript) are turned into a dlopen. AIUI, this is done by
gobject-introspection based on info found in .gir files.

In Guix, .gir files contain absolute file names of share libraries. At
run-time, ‘gobject-introspection-absolute-shlib-path.patch’ ensures that
dlopen 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 the
LD_LIBRARY_PATH wrapping above breaks something?

Thanks,
Ludo’.
R
R
Ricardo Wurmus wrote on 2 Dec 2021 10:54
gnome-shell: LD_LIBRARY_PATH setting propagates to entire session
(address . 37123-done@debbugs.gnu.org)
877dcnz5w3.fsf@elephly.net
Commit f1fd313e486491caf1ff5874810f2ee06091e825 removes LD_LIBRARY_PATH
from the wrapper. That’s on core-updates-frozen.

I reconfigured my system with this change and gnome-shell starts up
fine, and things like Gnome Weather work correctly. So I’m pretty
confident that we no longer need to do this.

Yay!

--
Ricardo
Closed
?