glibc-mesboot native inputs vs inputs

[Tadhg McDonald-Jensen]

Hello,

I'm trying to cross compile an OS definition for arm and I ran into an 
issue where it tried to compile glibc-mesboot from commencement.scm and 
failed because in the `setenv` phase it does:

> (let* ((headers (assoc-ref inputs "headers"))
>          (libc (assoc-ref inputs "libc"))
>          (gcc (assoc-ref inputs "gcc"))
And then uses `libc` in string-append, however these are all native 
inputs so when cross compiling this is the wrong way to access them and 
the build fails because the returned `#f` is the wrong data type.

I tried replacing these with `this-package-native-input` and it seemed 
to work but in the build log I noticed it also compiled a package called 
`glibc-cross-arm-linux-gnueabihf` so I'm wondering if depending on 
glibc-mesboot for arm was the real mistake, I'm not sure how to use 
`guix graph` for my own os definition instead of a named package so I'm 
not sure how to track down why there was a dependency on glibc-mesboot 
being cross compiled.

I've attached my os definition in case it helps, I'm compiling it with 
`guix system image --target=arm-linux-gnueabihf turris.scm`. I'm not 
asking for any specific help with that definition beyond knowing which 
part is trying to compile glibc-mesboot for arm and whether it is 
because I'm doing something wrong or there is an incorrect dependency 
for cross compiling or whether it is a bug in glibc-mesboot for not 
using `this-package-native-input`.

I hope this makes sense, thanks for your input,

Tadhg

turris.scm
Description: Text Data