bug#30879: Commit bc499b113 broke guix on guile@2.0.14, improper <operating-system> field initialization

[ludo@gnu.org (Ludovic Courtès)]

Hello Eric,

Sorry for the late reply.

Eric Bavier <bavier@cray.com> skribis:

> On Thu, Mar 22, 2018 at 12:04:06AM +0100, Ludovic Courtès wrote:
>> Eric Bavier <bavier@cray.com> skribis:
>> 
>> [...]
>> 
>> > In gnu/system.scm:
>> >  501: 3 [operating-system-services # # #f]
>> >  476: 2 [essential-services # # #f]
>> >  576: 1 [operating-system-etc-service #]
>> > In gnu/system/nss.scm:
>> >  217: 0 [name-service-switch->string (# # # # ...)]
>> >
>> > gnu/system/nss.scm:217:19: In procedure name-service-switch->string:
>> > gnu/system/nss.scm:217:19: In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): (#<<service> type: #<service-type login ...

[...]

> Oh, so it loks like .go files from the system-installed guix are being
> picked up:
>
> 53692 openat(AT_FDCWD, "/usr/local/lib/guile/2.0/site-ccache/gnu/system.go", O_RDONLY|O_CLOEXEC) = 10
>
> I hadn't expected that, but I suppose it makes sense.  Running make
> under ./pre-inst-env does not help.
>
> We should probably find a way to prevent this in general, right?

It seems that the problem here is that both Guile and Guix were
installed with --prefix=/usr/local.

Guile contains by default $prefix/lib/guile/2.0/site-ccache in its
%load-compiled-path.  Thus, it will always find the .go files of that
Guix that’s installed in the same prefix.

> We shouldn't be loading guix modules from outside the source tree
> during build.

In general we can (and do: see the ‘make-go’ target and see
‘pre-inst-env’), but in this case we can’t really prevent it because
$prefix/lib/… is in the default search path of Guile, which is
admittedly problematic.

Maybe we should just forbid install Guix in the same prefix as Guile,
and detect that at configure time.

WDYT?

Ludo’.