GNU bug report logs - #37123
gnome-shell: LD_LIBRARY_PATH setting propagates to entire session

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37123 in the body.
You can then email your comments to 37123 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: bug-guix <at> gnu.org
Subject: gnome-shell: LD_LIBRARY_PATH setting propagates to entire session
Date: Tue, 20 Aug 2019 15:21:37 -0400

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

Message #8 received at 37123 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: mhw <at> netris.org
Cc: 37123 <at> debbugs.gnu.org
Subject: Re: bug#37123: gnome-shell: LD_LIBRARY_PATH setting propagates to
 entire session
Date: Tue, 20 Aug 2019 21:38:58 +0200

Hi Mark,

> 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

--
Ricardo

Message #13 received at 37123 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: mhw <at> netris.org, 37123 <at> debbugs.gnu.org
Subject: Re: bug#37123: gnome-shell: LD_LIBRARY_PATH setting propagates to
 entire session
Date: Wed, 13 Nov 2019 23:02:52 +0100

Hello,

Ricardo Wurmus <rekado <at> elephly.net> skribis:

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

--8<---------------cut here---------------start------------->8---
     (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"))))
--8<---------------cut here---------------end--------------->8---

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

Message #18 received at 37123-done <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: 37123-done <at> debbugs.gnu.org
Subject: gnome-shell: LD_LIBRARY_PATH setting propagates to entire session
Date: Thu, 02 Dec 2021 09:54:51 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.