Léo Le Bouter <lle-b...@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.
