GNU bug report logs -
#30879
Stale .go files are loaded when Guile and Guix are in the same prefix
Previous Next
Full log
Message #23 received at 30879 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 22, 2018 at 12:04:06AM +0100, Ludovic Courtès wrote:
> Eric Bavier <bavier <at> 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.
This bug report was last modified 7 years and 31 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.