unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Carlo Zancanaro <carlo@zancanaro.id.au>
Cc: help-guix@gnu.org
Subject: Re: Can I easily install GNU Emacs 27.1.50 via Guix?
Date: Fri, 18 Dec 2020 11:38:23 +0100	[thread overview]
Message-ID: <86eejnmmao.fsf@gmail.com> (raw)
In-Reply-To: <8736034fsk.fsf@zancanaro.id.au>

Hi,

On Fri, 18 Dec 2020 at 20:36, Carlo Zancanaro <carlo@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


  reply	other threads:[~2020-12-18 11:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09 16:46 Can I easily install GNU Emacs 27.1.50 via Guix? Jorge P. de Morais Neto
2020-12-09 20:56 ` Pierre Neidhardt
2020-12-10 12:40   ` zimoun
2020-12-17 22:54     ` Jorge P. de Morais Neto
2020-12-17 22:59       ` Jorge P. de Morais Neto
2020-12-18  2:05       ` zimoun
2020-12-18  4:03         ` Carlo Zancanaro
2020-12-18  9:00           ` zimoun
2020-12-18  9:36             ` Carlo Zancanaro
2020-12-18 10:38               ` zimoun [this message]
2020-12-18 11:37                 ` Carlo Zancanaro
2020-12-18 13:59                   ` zimoun
2020-12-19  0:17                     ` Carlo Zancanaro
2020-12-18 10:44               ` Dr. Arne Babenhauserheide
2020-12-18 12:55                 ` Ricardo Wurmus
2020-12-18 14:05                   ` zimoun
2020-12-18 15:33                   ` Maxim Cournoyer
2020-12-18 15:09               ` Jorge P. de Morais Neto
2020-12-18 23:17                 ` Carlo Zancanaro
2020-12-18  9:50           ` Ricardo Wurmus
2020-12-10 12:27 ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86eejnmmao.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=carlo@zancanaro.id.au \
    --cc=help-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).