--- Begin Message ---
|
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
--- End Message ---
--- Begin Message ---
|
Subject: |
gnome-shell: LD_LIBRARY_PATH setting propagates to entire session |
|
Date: |
Thu, 02 Dec 2021 09:54:51 +0000 |
|
User-agent: |
mu4e 1.6.6; emacs 27.2 |
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
--- End Message ---