Problem with guix.el on hybrid systems.

  • Done
  • quality assurance status badge
Details
3 participants
  • Alex Kost
  • Ludovic Courtès
  • Mathieu Lirzin
Owner
unassigned
Submitted by
Mathieu Lirzin
Severity
normal
M
M
Mathieu Lirzin wrote on 24 Jul 2015 14:25
(address . bug-guix@gnu.org)
876159eo9i.fsf@openmailbox.org
Hello Guix,

A long time ago I've noticed some problems with guix.el when installing
Guile from Guix. My setup Guix 0.8.3 built from the tarball and
installed ontop of Debian 8 in the /usr/local prefix (nothing fancy :)).
At this state everything works fine, guix.el included!

First for Guix to be useful I change my paths to choose
"$HOME/.guix-profile/...", then I install Guile in my profile, and
eventually when I launch the emacs interface, Guix yells at me.

Toggle snippet (34 lines)
Backtrace:
In guix/derivations.scm:
19: 19 [#<procedure 13edac0 ()>]
In ice-9/boot-9.scm:
2951: 18 [define-module* (guix derivations) #:filename ...]
2926: 17 [resolve-imports (((srfi srfi-1)) ((srfi srfi-9)) ((srfi srfi-9 gnu)) ...)]
2864: 16 [resolve-interface (guix hash) #:select ...]
2789: 15 [#<procedure e19880 at ice-9/boot-9.scm:2777:4 (name #:optional autoload version #:key ensure)> # ...]
3065: 14 [try-module-autoload (guix hash) #f]
2401: 13 [save-module-excursion #<procedure 177b270 at ice-9/boot-9.scm:3066:17 ()>]
3085: 12 [#<procedure 177b270 at ice-9/boot-9.scm:3066:17 ()>]
In unknown file:
?: 11 [primitive-load-path "guix/hash" ...]
In guix/hash.scm:
19: 10 [#<procedure 177f2e0 ()>]
In ice-9/boot-9.scm:
2951: 9 [define-module* (guix hash) #:filename ...]
2926: 8 [resolve-imports ((#) (#) (#) (#) ...)]
2864: 7 [resolve-interface (guix gcrypt) #:select ...]
2789: 6 [#<procedure e19880 at ice-9/boot-9.scm:2777:4 (name #:optional autoload version #:key ensure)> # ...]
3065: 5 [try-module-autoload (guix gcrypt) #f]
2401: 4 [save-module-excursion #<procedure 177b000 at ice-9/boot-9.scm:3066:17 ()>]
3085: 3 [#<procedure 177b000 at ice-9/boot-9.scm:3066:17 ()>]
In unknown file:
?: 2 [primitive-load-path "guix/gcrypt" ...]
In guix/gcrypt.scm:
33: 1 [#<procedure 1784720 ()>]
In unknown file:
?: 0 [dynamic-link "libgcrypt"]

ERROR: In procedure dynamic-link:
ERROR: In procedure dynamic-link: file: "libgcrypt", message: "file not found"

what is happening is that Guix uses Guile installed from Guix but is
unable to dynamically link with the Libgcrypt from debian or even with
the Libgcrypt installed from guix in my profile.

So my current fix is to add (setq guix-guile-program "/usr/bin/guile")
to my .emacs file, then everything works fine. But what should we do to
avoid such thing? AIUI we could document it in
(info "(guix)Application Setup") or (info "(guix)Emacs Initial Setup"),
or even better fix it directly in the code (if possible).

Here is my attempt to fix the code with my naïve elisp programming. I
would be happy to get better suggestion!
--
Mathieu Lirzin
L
L
Ludovic Courtès wrote on 24 Jul 2015 22:31
(name . Mathieu Lirzin)(address . mthl@openmailbox.org)
87h9otfgbs.fsf@gnu.org
Mathieu Lirzin <mthl@openmailbox.org> skribis:

Toggle quote (12 lines)
> From ca4360cc33f56dbfd1fa1367f68d3bd3d0d7c553 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin <mthl@openmailbox.org>
> Date: Fri, 24 Jul 2015 12:59:20 +0200
> Subject: [PATCH] emacs: Fix guix-guile-program.
>
> * emacs/guix-backend.el: Move to ...
> * emacs/guix-backend.el.in: ... here.
> (guix-guile-program): Default to the Guile used when building Guix to
> avoid breaking guix.el when installing another Guile.
> * configure.ac: Adapt to it.
> * .gitignore: Likewise.

[...]

Toggle quote (2 lines)
> +(defvar guix-guile-program "@GUILE@"

Sounds reasonable to me.

Alternately, I wonder if it would make sense to define that variable in
guix-init.el to avoid having an additional .in file.

Alex, WDYT?

Thanks,
Ludo'.
A
A
Alex Kost wrote on 25 Jul 2015 09:52
(name . Ludovic Courtès)(address . ludo@gnu.org)
87fv4c3c9a.fsf@gmail.com
Ludovic Courtès (2015-07-24 23:31 +0300) wrote:

Toggle quote (25 lines)
> Mathieu Lirzin <mthl@openmailbox.org> skribis:
>
>> From ca4360cc33f56dbfd1fa1367f68d3bd3d0d7c553 Mon Sep 17 00:00:00 2001
>> From: Mathieu Lirzin <mthl@openmailbox.org>
>> Date: Fri, 24 Jul 2015 12:59:20 +0200
>> Subject: [PATCH] emacs: Fix guix-guile-program.
>>
>> * emacs/guix-backend.el: Move to ...
>> * emacs/guix-backend.el.in: ... here.
>> (guix-guile-program): Default to the Guile used when building Guix to
>> avoid breaking guix.el when installing another Guile.
>> * configure.ac: Adapt to it.
>> * .gitignore: Likewise.
>
> [...]
>
>> +(defvar guix-guile-program "@GUILE@"
>
> Sounds reasonable to me.
>
> Alternately, I wonder if it would make sense to define that variable in
> guix-init.el to avoid having an additional .in file.
>
> Alex, WDYT?

Mathieu, thanks for catching it! I also think that it is better to
avoid converting "guix-backend.el" into ".in" file.

I had the same question with 'guix-load-path' variable when Emacs UI was
merging into Guix: this var was defined in "guix-backend.el" but it had
to depend on @prefix@, so I just put another "(defvar …)" into
"guix-init.el.in". As you can see there are 2 definitions of
'guix-load-path':

- in "guix-backend.el" (with an old "configure"-independent value)

- and in "guix-init.el" (with the current default value).

So I suggest to do the same with 'guix-guile-program', i.e. to put

(defvar guix-guile-program "@GUILE" …)

into "guix-init.el.in" and that's it. Since "guix-init.el" is loaded
the first, "defvar" in "guix-backend.el" will not override the default
value.

--
Alex
L
L
Ludovic Courtès wrote on 11 Sep 2015 19:26
(name . Mathieu Lirzin)(address . mthl@openmailbox.org)(address . 21127-done@debbugs.gnu.org)
87io7gc1eu.fsf@gnu.org
Mathieu Lirzin <mthl@openmailbox.org> skribis:

F> So my current fix is to add (setq guix-guile-program "/usr/bin/guile")
Toggle quote (8 lines)
> to my .emacs file, then everything works fine. But what should we do to
> avoid such thing? AIUI we could document it in
> (info "(guix)Application Setup") or (info "(guix)Emacs Initial Setup"),
> or even better fix it directly in the code (if possible).
>
> Here is my attempt to fix the code with my naïve elisp programming. I
> would be happy to get better suggestion!

This bug was fixed in 7061938, so closing it.

Thanks,
Ludo’.
Closed
?