help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Running shepherd as user: incompatible bytecode version


From: elaexuotee
Subject: Re: Running shepherd as user: incompatible bytecode version
Date: Mon, 19 Apr 2021 01:49:49 +0900
User-agent: mblaze/1.1

Léo Le Bouter <lle-bout@zaclys.net> wrote:
> I get the same issue, the shepherd package uses GNU Guile 3.0.2 and GNU
> Guix provides GNU Guile 3.0.5 under the 'guile' package specification
> name.
> 
> I am not sure this is the cause, since shepherd is wrapped to use GNU
> Guile 3.0.2.
> 
> I am also still looking for a solution.
> 
> Léo

Thanks for the quick sanity check.

I spent a little time looking into this. The problem seems to be that Shepherd
is executed from Guile 3.0.2 while its %load-compiled-path contains compiled
modules for 3.0.5.

This ultimately stems from the fact that the `guix' package has
`guile-3.0-latest' on its inputs while while `shepherd' has just `guile-3.0'.

Ideally, we'd just update Shepherd to use the same Guile as guix, but
unfortunately, Shepherd (currently, 0.8.1) fails several of its tests if you
naively try replacing the input. I have also been hitting unrelated build
obstacles trying to test building against master.

Anyway, if we must stick with Guile 3.0.2, then maybe it makes sense to include
something like a guile-module-union (from guix/self.scm) and shove this into
the %load-path and $load-compiled-path of the /bin/shepherd script. I haven't
looked too deeply into doing this yet.

Finally, as a quick workaround, you can call shepherd with an empty
%load-compiled-path to supress the warnings:

    $ GUILE_LOAD_COMPILED_PATH= shepherd

All the modules will still need to be run through the interpreter, though, so
startup time remains horrendously slow when using that fccache example.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]