unsupported mips64el architecture can cause cryptic backtraces

> Hello,

>

> This issue was triggered by having make-uboot-package uses #:target [0],

> but it already exists on current master. I've spent some time narrowing

> down the issue, and it is caused by the package returned by

> cross-kernel-headers in (gnu packages cross-base) being produced with a

> bogus arguments field, or at least one that can't be access via the

> package-arguments accessor:

>

> (use-modules (guix packages)

> (gnu packages cross-base))

>

> (define linux-libre-headers-cross-mips64el-linux-gnuabi64

> (cross-kernel-headers "mips64el-linux-gnuabi64"))

>

> (package-arguments linux-libre-headers-cross-mips64el-linux-gnuabi64)

>

> ice-9/boot-9.scm:1685:16: In procedure raise-exception:

> In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f

>

> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.

> scheme@(guix-user) [1]> ,bt

> In gnu/packages/cross-base.scm:

> 388:33 1 (loop (#:phases (modify-phases %standard-phases (delete (quote configure)) (# (…) …) …) …) …)

> In ice-9/boot-9.scm:

> 1685:16 0 (raise-exception _ #:continuable? _)

>

> [0] https://issues.guix.gnu.org/60224#30

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

>> This issue was triggered by having make-uboot-package uses #:target [0],

>> but it already exists on current master. I've spent some time narrowing

>> down the issue, and it is caused by the package returned by

>> cross-kernel-headers in (gnu packages cross-base) being produced with a

>> bogus arguments field, or at least one that can't be access via the

>> package-arguments accessor:

> OK, I think I've found the culprit:

>

> (setenv "ARCH" ,(platform-linux-architecture

> (lookup-platform-by-target target)))