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

[Eric Bavier <bavier@cray.com>]

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 ...
> 
> This looks like another record issue: the code is accessing the
> `services' field instead of the `name-service-switch' field, which is
> right next to it.
> 
> So it looks like there are still stale .go files somewhere being picked
> up.  This time it would mean that nss.go is up-to-date and system.go is
> stale, since nss.go assumes an offset for `name-service-switch' that is
> +1 compared to that of system.go.
> 
> Could you maybe try:
> 
>   rm -rf ~/.cache/guile
>   make clean-go
>   strace -f -o log make
> 
> and check in `log' whether .go files outside of the build tree are being
> used?

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?  We
shouldn't be loading guix modules from outside the source tree during
build.

-- 
Eric Bavier, Scientific Libraries, Cray Inc.