> [...]
>
> > As "libc" currently doesn't exist in 'inputs', that means "libc"
> > is searched for in 'native-inputs', which is probably not what you want,
> > given that you are cross-compiling?
> 
> Are you saying that ‘%build-inputs’ is the union of ‘inputs’  and ‘native-
> inputs’? For my own education, do you know where that happens?
> 
> The manual and the doc string for ‘build-expression->derivation’ only 
> mention that it comes from ‘inputs’. I can send a patch to correct them.

I thought "build-expression->derivation" doesn't define %build-inputs
anymore, but apparently it does.  However, note that, on core-updates
at least, gnu-build and gnu-cross-build don't use build-expression->derivation,
instead they use gexp->derivation (see (guix build-system gnu)), and gexp->derivation
doesn't define %build-inputs.

gexp->derivation doesn't define %build-inputs, but gnu-build and gnu-cross-build
do:

        ;; also see with-build-variables
        (define %build-host-inputs
          #+(input-tuples->gexp build-inputs))

        (define %build-target-inputs
          (append #$(input-tuples->gexp host-inputs)
                  #+(input-tuples->gexp target-inputs)))

        (define %build-inputs
          (append %build-host-inputs %build-target-inputs))
        ;; ^ the unio native-inputs, inputs and implicit inputs!

        (define %outputs
          #$(outputs->gexp outputs))

I'm not familiar with 'host-inputs', 'build-inputs' and 'target-inputs'.
They are a ‘bag’ thing, not a ‘package’ thing.  You'll have to look at
'lower' to see how native-inputs and inputs are mapped to host-inputs,
build-inputs and target-inuts.

Greetings,
Maxime.