Stale .go files are loaded when Guile and Guix are in the same prefix

Hello Guix,

On the master branch (5d818b3557cc3b546d5bd0639359c14c7c0ab685), when

configured with guile@2.0.14, I get the following backtrace when

running `make`.

Backtrace:

In ice-9/boot-9.scm:

1739: 19 [#<procedure 34ebc6c0 ()>]

In unknown file:

?: 18 [primitive-load "/home/users/bavier/src/guix/./build-aux/compile-all.scm"]

In guix/build/compile.scm:

158: 17 [compile-files "." "/home/users/bavier/src/guix" ...]

107: 16 [load-files "." # # ...]

In ice-9/boot-9.scm:

2900: 15 [resolve-interface (gnu tests base) #:select ...]

2825: 14 [#<procedure 34dfc200 at ice-9/boot-9.scm:2813:4 (name #:optional autoload version #:key ensure)> # ...]

3101: 13 [try-module-autoload (gnu tests base) #f]

2412: 12 [save-module-excursion #<procedure 35c46750 at ice-9/boot-9.scm:3102:17 ()>]

3121: 11 [#<procedure 35c46750 at ice-9/boot-9.scm:3102:17 ()>]

In unknown file:

?: 10 [primitive-load-path "gnu/tests/base" ...]

In gnu/tests/base.scm:

390: 9 [#<procedure 38c523a0 ()>]

63: 8 [run-basic-test # # "basic" ...]

In ice-9/eval.scm:

387: 7 [eval # #]

387: 6 [eval # #]

411: 5 [eval # #]

387: 4 [eval # #]

In unknown file:

?: 3 [filter #<procedure 35c461e0 at ice-9/eval.scm:416:20 (a)> (# # # #)]

In ice-9/eval.scm:

411: 2 [eval # #]

411: 1 [eval # #]

387: 0 [eval # #]

ice-9/eval.scm:387:11: In procedure eval:

ice-9/eval.scm:387:11: In procedure mapped-device-target: Wrong type argument: #<<file-system> device: "my-root" title: label mount-point: "/" type: "ext4" flags: () options: #f mount?: #t needed-for-boot?: #f check?: #t create-mount-point?: #f dependencies: () location: ((line . 209) (column . 24) (filename . "gnu/tests.scm"))>

(as an aside: maybe would could postpone compilation of test modules

until `make check`).

I git bisect'd this failure to commit

bc499b113a598c0e7863da9887a4133472985713, which added the

'initrd-modules' field to the (@ (gnu system) <operating-system>)

record.

The %simple-os from (gnu tests base) seems improperly initialized. In

particular, the fields seem to be shifted:

scheme@(guile-user)> (@@ (gnu tests base) %simple-os)

$1 = #<<operating-system>

kernel: #<package linux-libre@4.15.7 ...>

kernel-arguments: ()

bootloader: #<<bootloader-configuration> bootloader: ...>

initrd: #<procedure base-initrd ...>

initrd-modules: ()

firmware: "komputilo"

host-name: #f

hosts-file: ()

mapped-devices: (#<<file-system> device: "my-root" ...> #<<file-system> ...> ...)

file-systems: ()

swap-devices: (#<<user-account> name: "alice" ...> ...)

...

Notice e.g. the "firmware" field has that value that should be in

"host-name", which has the value "hosts-file" should have, and

"mapped-devices" has the value "file-systems" should have, etc.

If you explicitely specify the new "initrd-modules" field this commit

added in (@ (gnu tests) %simple-os), then compilation proceeds as

expected.

--

Eric Bavier, Scientific Libraries, Cray Inc.

Hello Eric,

Eric Bavier <bavier@cray.com> skribis:

That sounds a lot like regular ABI breakage: a new <operating-system>

field was added but gnu/tests/base.go wasn’t rebuilt, and thus was

expecting the previous struct layout.

Does “rm gnu/tests/base.go && make” suffice to fix this issue?

Thanks,

Ludo’.

On Wed, Mar 21, 2018 at 12:12:02AM +0100, Ludovic Courtès wrote:

No, it doesn't help. Previously I had been running "make clean-go"

before each "make.

The error/backtrace is issued when build-aux/compile-all.scm tries to

load gnu/tests/base.scm, before it even gets to compilation.

--

Eric Bavier, Scientific Libraries, Cray Inc.

Eric Bavier <bavier@cray.com> skribis:

Oh, can you “rm -rf ~/.cache/guile”?

One thing that could be an issue is that (gnu system install) loads

‘examples/bare-bones.tmpl’. Thus ‘bare-bones.tmpl.go’ ends up in

~/.cache/guile and could be out of sync.

Thanks,

Ludo’.

On Wed, Mar 21, 2018 at 10:04:00PM +0100, Ludovic Courtès wrote:

"rm -rf ~/.cache/guile && make clean-go && make" resulted in an error,

but a slightly different backtrace:

```

LOAD gnu/tests/base.scm

Backtrace:

In ice-9/eval.scm:

432: 19 [eval # #]

In ice-9/boot-9.scm:

2412: 18 [save-module-excursion #<procedure 2998d7c0 at ice-9/boot-9.scm:4084:3 ()>]

4091: 17 [#<procedure 2998d7c0 at ice-9/boot-9.scm:4084:3 ()>]

1734: 16 [%start-stack load-stack ...]

1739: 15 [#<procedure 299b26c0 ()>]

In unknown file:

?: 14 [primitive-load "/home/users/bavier/src/guix/./build-aux/compile-all.scm"]

In guix/build/compile.scm:

158: 13 [compile-files "." "/home/users/bavier/src/guix" ...]

107: 12 [load-files "." # # ...]

In ice-9/boot-9.scm:

2900: 11 [resolve-interface (gnu tests base) #:select ...]

2825: 10 [#<procedure 298f2200 at ice-9/boot-9.scm:2813:4 (name #:optional autoload version #:key ensure)> # ...]

3101: 9 [try-module-autoload (gnu tests base) #f]

2412: 8 [save-module-excursion #<procedure 30cd0ed0 at ice-9/boot-9.scm:3102:17 ()>]

3121: 7 [#<procedure 30cd0ed0 at ice-9/boot-9.scm:3102:17 ()>]

In unknown file:

?: 6 [primitive-load-path "gnu/tests/base" ...]

In gnu/tests/base.scm:

390: 5 [#<procedure 30cdae40 ()>]

63: 4 [run-basic-test # # "basic" ...]

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 ...

```

--

Eric Bavier, Scientific Libraries, Cray Inc.

Eric Bavier <bavier@cray.com> skribis:

[...]

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?

Thanks,

Ludo'.

On Thu, Mar 22, 2018 at 12:04:06AM +0100, Ludovic Court�s wrote:

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.

Hello,

Eric Bavier <bavier@cray.com> skribis:

From my Guix build and source tree, I see this:

Don’t you get a similar message?

Thanks,

Ludo’.

On Thu, Mar 22, 2018 at 05:19:04PM +0100, Ludovic Courtès wrote:

No, I get

--

Eric Bavier, Scientific Libraries, Cray Inc.

As a workaround, I temporarily uninstalled Guix from the system. This

allowed compilation from my git checkout to succeed.

--

Eric Bavier, Scientific Libraries, Cray Inc.

severity 30879 important

Hello Eric,

Sorry for the late reply.

Eric Bavier <bavier@cray.com> skribis:

[...]

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.

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’.

retitle 30879 Stale .go files are loaded when Guile and Guix are in the same prefix