On Thu, Mar 22, 2018 at 12:04:06AM +0100, Ludovic Court�s wrote: > Eric Bavier 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): (#< type: # > 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.