cross-base error: wrong type argument in position 1

  • Open
  • quality assurance status badge
Details
3 participants
  • Josselin Poiret
  • Ekaitz Zarraga
  • Maxime Devos
Owner
unassigned
Submitted by
Ekaitz Zarraga
Severity
normal
E
E
Ekaitz Zarraga wrote on 7 Jun 2022 17:43
5qR8o5eSldiy3chXSPnE2qn1NtHm4FklEGx9APhm0xFagHrv8fZapayVEMvdtJ4Kqw6vTwbyu3rCyPc38oEbJq78X2XW7RwWoe3DzND_K_w=@elenq.tech
Hi all,

I'm experiencing the following error when I try to make something like (cross-libc "riscv64-unknown-linux-gnu") and it broke in every single setup I already have for months and was working properly. In fact, it works as expected when using a time-machine to the past.

```
$ guix shell -m manifest.scm
Backtrace:
In guix/scripts/environment.scm:
953:13 19 (_)
In guix/store.scm:
2168:25 18 (run-with-store #<store-connection 256.99 7f651e026870> …)
In guix/scripts/environment.scm:
955:14 17 (_ _)
In guix/profiles.scm:
627:3 16 (_ _)
In srfi/srfi-1.scm:
586:29 15 (map1 (#<<manifest-entry> name: "gcc" version: "4.6.…> …))
586:29 14 (map1 (#<<manifest-entry> name: "binutils-cross-risc…> …))
586:17 13 (map1 (#<<manifest-entry> name: "glibc-cross-riscv64…> …))
In guix/profiles.scm:
1889:19 12 (_ _)
In guix/packages.scm:
1269:17 11 (supported-package? #<package glibc-cross-riscv64-unkn…> …)
In guix/memoization.scm:
101:0 10 (_ #<hash-table 7f650b8bae00 153/223> #<package glibc-…> …)
In guix/packages.scm:
1239:12 9 (_)
In srfi/srfi-1.scm:
460:18 8 (fold #<procedure 7f650ba4b540 at guix/packages.scm:12…> …)
In guix/packages.scm:
1243:42 7 (_ _ ("x86_64-linux" "i686-linux"))
In guix/memoization.scm:
101:0 6 (_ #<hash-table 7f650b8bae00 153/223> #<package linux-…> …)
In guix/packages.scm:
1247:37 5 (_)
1507:16 4 (package->bag _ _ _ #:graft? _)
1612:43 3 (thunk)
In gnu/packages/cross-base.scm:
352:33 2 (loop (#:phases (modify-phases %standard-phases # …) …) #)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f
```

I think the error was introduced in the commit b55310603f0df7d5ae02d47cb8d4be58bf1d41ca but I can't really explain what's happening.

You can replicate this using the manifest from: https://github.com/ekaitz-zarraga/gcc

It won't work if you have guix updated, but it will if you use the time-machine with the `channels.scm` file in the same repo.

You can also try with smaller packages (the repo is a full gcc4.6, use it under your own risk (: ), anything that uses `(cross-libc "riscv64-unknown-linux-gnu")` will trigger the error.

I would fix this myself but I don't really understand what's going on. If anyone guides me a little I'm open to fix it myself.

Thank you all!
Ekaitz

ElenQ Technology
Ethical Innovation
M
M
Maxime Devos wrote on 7 Jun 2022 20:33
eb961bdb61d352de2771a188441c5ded8364da96.camel@telenet.be
Ekaitz Zarraga schreef op di 07-06-2022 om 15:43 [+0000]:
Toggle quote (2 lines)
> I think the error was introduced in the commit b55310603f0df7d5ae02d47cb8d4be58bf1d41ca but I can't really explain what's happening.

I guess it's due to the introduction of

lookup-platform-by-target-or-system

Proposed solution:

* rename platform-linux-architecture to
'%platform-linux-architecture'
and define a wrapper 'platform-linux-architecture' displaying
a proper error message ‘unsupported target’ or such.

and

* use "riscv64-linux-gnu" instead of "riscv64-unknown-linux-gnu"
(as expected by (guix platforms riscv)).

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYp+aFhccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7qNgAP4y+z5kehiIbeO+hRvARMS1STbc
yovf4rlfW6d2a7+CRwEA7svONvdr3HPsm+T6IB9CB18q7mxynGf8EfRc1h4gxgA=
=SXjG
-----END PGP SIGNATURE-----


J
J
Josselin Poiret wrote on 8 Jun 2022 12:35
877d5rwigy.fsf@jpoiret.xyz
Hello Maxime and Ekaitz,
Maxime Devos <maximedevos@telenet.be> writes:

Toggle quote (13 lines)
> Ekaitz Zarraga schreef op di 07-06-2022 om 15:43 [+0000]:
> Proposed solution:
>
> * rename platform-linux-architecture to
> '%platform-linux-architecture'
> and define a wrapper 'platform-linux-architecture' displaying
> a proper error message ‘unsupported target’ or such.
>
> and
>
> * use "riscv64-linux-gnu" instead of "riscv64-unknown-linux-gnu"
> (as expected by (guix platforms riscv)).

I don't think we should deviate from the usual behaviour of a procedure
returning #f it wasn't able to find the thing it was searching for.
Ideally, cross-libc should take a platform argument itself, so that we
can lookup the target earlier and throw an exception there instead.

WDYT?

Best,
--
Josselin Poiret
M
M
Maxime Devos wrote on 8 Jun 2022 15:06
f478f45c1b318d7abb562468b9f3cdca8b2076e3.camel@telenet.be
Josselin Poiret schreef op wo 08-06-2022 om 12:35 [+0200]:
Toggle quote (14 lines)
> >    * rename platform-linux-architecture to
> >      '%platform-linux-architecture'
> >      and define a wrapper 'platform-linux-architecture' displaying
> >      a proper error message ‘unsupported target’ or such.
> >
> > and
> >
> >    * use "riscv64-linux-gnu" instead of "riscv64-unknown-linux-gnu"
> >      (as expected by (guix platforms riscv)).
>
> I don't think we should deviate from the usual behaviour of a
> procedure
> returning #f it wasn't able to find the thing it was searching for.

The proposal was to modify platform-linux-architecture, which doesn't
search for anything and doesn't return #false. It already throws an
exception:

Toggle quote (4 lines)
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure struct-vtable: Wrong type argument in position 1
> (expecting struct): #f

The proposal is to make the error message clearer, by raising an
exception ourselves instead of leaving it to struct-vtable.

(My proposal might have been confusing due to the mention of
lookup-platform-by-target-or-system which doesn't seem relevant on
second sight?)

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYqCewhccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7kHkAP4m4wrF7q24/IYCaAe9bB2YYYyO
W9OZNwh4e5orKdPzTgD+KrDFwdrTQCYqsy2ruXPyhGZZeDqnOHiqku1B5bda3wc=
=3gEg
-----END PGP SIGNATURE-----


M
M
Maxime Devos wrote on 8 Jun 2022 15:12
7a7d7becd3cfb7f05c3e04fbbc98b04250b297f9.camel@telenet.be
Josselin Poiret schreef op wo 08-06-2022 om 12:35 [+0200]:
Toggle quote (5 lines)
> I don't think we should deviate from the usual behaviour of a procedure
> returning #f it wasn't able to find the thing it was searching for.
> Ideally, cross-libc should take a platform argument itself, so that we
> can lookup the target earlier and throw an exception there instead.

Wait my proposal cannot work as-is because linux-architecture=#false
for Hurd platforms ...

FWIW, I think the current usual behaviour is not ideal, and that these
kind of procedures should raise an exception instead, like
specification->package:

scheme@(guix-user)> (specification->package "foobar")
guix repl: fout: foobar: onbekend pakket ; <-- unknown package

Or search-input-file or search-input-directory.

Maybe it could raise a &non-linux-platform condition like
search-input-file raises &search-error condition?

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYqCgIBccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7nI0AP9DzFJ0CeDkmWGOWd8APD9OyTvM
pLHwT6n6C4OeWjFHWAEAtUKeHv/nsJSUtFXPStd2MaNJJpOGDoHLIH+WQxEuVQk=
=XfJd
-----END PGP SIGNATURE-----


E
E
Ekaitz Zarraga wrote on 8 Jun 2022 18:29
(name . Maxime Devos)(address . maximedevos@telenet.be)
ZnQyWD0ObmbPJCLuz__m3KgBWHwliJEAUWPQiFg76p2m6QBfi3uFfWTqN7lt3dpCsKe9vJ8W371i01jeHxDYTkG7YHiKSY4ae58caA9u94E=@elenq.tech
Hi,

Toggle quote (4 lines)
> * use "riscv64-linux-gnu" instead of "riscv64-unknown-linux-gnu"
> (as expected by (guix platforms riscv)).


There's an slight problem with that. I tried to do it and I can't
build my custom gcc without sending the full triplet (with -unknown)
and if I make the other parts of the system, like binutils without the
-unknown part, the gcc is unable to find `ld`.

I have to dig on this further but it looks like this has further
effects on the system.

Best,
Ekaitz
E
E
Ekaitz Zarraga wrote on 8 Jun 2022 19:11
(name . Maxime Devos)(address . maximedevos@telenet.be)
AfJ8NsB9JmSRw7tZXUqCDGDXhYGmEsTJYJF-tcmGcULzYcQvkQ6u9PFYWdv5mBFpza3hvqYyiRXpwPxu63xnxXLoroAbGTyDuAH-y8jnqxc=@elenq.tech
Forget it, there was some code missing to match the platform correctly in my
custom GCC. Added it and now it's working without the `unknown` part.

Cheers
?