cross-base error: wrong type argument in position 1

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

Ekaitz Zarraga schreef op di 07-06-2022 om 15:43 [+0000]:

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.

Hello Maxime and Ekaitz,

Maxime Devos <maximedevos@telenet.be> writes:

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

Josselin Poiret schreef op wo 08-06-2022 om 12:35 [+0200]:

The proposal was to modify platform-linux-architecture, which doesn't

search for anything and doesn't return #false. It already throws an

exception:

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.

Josselin Poiret schreef op wo 08-06-2022 om 12:35 [+0200]:

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.

Hi,

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

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