Hi, On Fri, 18 Dec 2020 at 20:36, Carlo Zancanaro <ca...@zancanaro.id.au> wrote:
> On Fri, Dec 18 2020, zimoun wrote: >> Maybe I miss something and I have not dove into all the details >> so I could be totally wrong. However, from my understanding, A >> is built against the shared library C1, and B is built against >> the shared library C2, and nothing says that C1 and C2 are >> compatible. > > This is true if they are in the same address space, but in this > case evince runs as a separate process. There's no reason it has > to load the same libraries as emacs, or have the same GTK_PATH > variable. You should be able to show this by replacing evince with > a script that unsets GTK_PATH before invoking the system evince. I > have attached such a wrapper, if you want to add it to your path > to check on a foreign distribution (it makes the print dialog in > evince work for me, even when I run evince from within Guix's > emacs). Is your point that: guix environment --ad-hoc emacs coreutils diffutils --pure env > /tmp/env.xterm emacs -q -f shell (emacs) env > /tmp/env.emacs diff /tmp/env.xterm /tmp/env.emacs --8<---------------cut here---------------start------------->8--- 1a2,3 > TERMCAP= > INSIDE_EMACS=27.1,comint 7a10 > COLUMNS=115 9c12,13 < TERM=xterm-256color --- > TERM=dumb > GTK_PATH=/gnu/store/v3rqcgz6chnmv2sg7lgf4s9kv2xyb5rl-gtk+-3.24.23/lib/gtk-3.0 11c15 < SHLVL=1 --- > SHLVL=2 14c18 < PS1=[env]\n\w/\n\u@\h$ --- > XDG_DATA_DIRS=/gnu/store/jqyb550ir6m374sd34qw5970lgj103xw-shared-mime-info-1.15/share:/gnu/store/rxg53s8xwc70lpbpp0bfsx89387ahclb-glib-2.62.6/share:/gnu/store/v3rqcgz6chnmv2sg7lgf4s9kv2xyb5rl-gtk+-3.24.23/share:/gnu/store/929jj5kcwg5c01ksdpml3r1nhlgz9k3b-emacs-27.1/share --8<---------------cut here---------------end--------------->8--- so GTK_PATH and maybe XDG_DATA_DIRS should not be there? However, on my machine running Guix on the top of Debian, I get: --8<---------------cut here---------------start------------->8--- guix environment --ad-hoc emacs grep coreutils --pure env | grep GTK_PATH /usr/bin/evince # Works! emacs -q -f shell sh-5.0$ env | grep GTK_PATH GTK_PATH=/gnu/store/v3rqcgz6chnmv2sg7lgf4s9kv2xyb5rl-gtk+-3.24.23/lib/gtk-3.0 sh-5.0$ /usr/bin/evince (evince:21780): GLib-GIO-ERROR **: 11:24:25.706: No GSettings schemas are installed on the system Trace/breakpoint trap sh-5.0$ unset GTK_PATH sh-5.0$ env | grep GTK_PATH sh-5.0$ /usr/bin/evince (evince:25064): GLib-GIO-ERROR **: 11:32:22.826: No GSettings schemas are installed on the system Trace/breakpoint trap --8<---------------cut here---------------end--------------->8--- So the story seems more complicated than GTK_PATH. :-) > One may argue that the system is functioning correctly, and this > is an unfortunate consequence of the way that Guix works. I would > still consider the faulty behaviour a bug - even if it is a result > of intentional decisions made in Guix's design. Running evince > (i.e. /usr/bin/evince) is failing because of an environment > variable that Guix's wrapper sets for emacs. That environment > variable is propagated to child processes (as environment > variables are), and in this instance that causes the child process > to misbehave. This is a bug caused by Guix's wrapping of emacs. I have no opinion. Even if usually, I prefer that by default the child (M-x shell) inherits from parent. >>> I run into a similar problem where my window manager >>> (awesomewm) sets LD_LIBRARY_PATH, which then propagates to >>> everything I run from my session. It's quite a pain. I thought >>> there was an open issue for this, but I can't seem to find it >>> at the moment. >> >> On foreign distro or Guix System? > > I am using Guix on a foreign distribution. I imagine a Guix system > would mask this bug because we wrap lots of programs (using > wrap-program or similar) so that they explicitly set the > environment variables they run with, but it may still be possible > to provoke it Guix built binaries. I haven't tried. Thanks for the explanations. All the best, simon
