[bug#49565] [PATCH] gnu: glibc-headers-mesboot: Use %build-inputs in setenv phase

[Thiago Jung Bauermann]

Hello Maxime,

Thanks for your help.

Em quinta-feira, 15 de julho de 2021, às 09:58:54 -03, Maxime Devos 
escreveu:
> Thiago Jung Bauermann via Guix-patches via schreef op wo 14-07-2021 om 
21:46 [-0300]:
> > When cross-building from x86-64-linux to powerpc64le-linux,
> > (assoc-ref inputs "libc") returns #f so get it from %build-inputs
> > instead.
> > 
> > For consistency, do the same for the other inputs as well.
> > 
> > * gnu/packages/commencement.scm (glibc-headers-mesboot)[arguments]: Get
> > packages from ‘%build-inputs’ rather than ‘inputs’.
> > ---
> > 
> >  gnu/packages/commencement.scm | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > When running
> > 
> > ```
> > $ ./pre-inst-env guix build \
> > 
> >     --target=powerpc64le-linux-gnu.gcc \
> >     gcc-toolchain@11
> > 
> > ```
> 
> To be clear: are you trying to cross-compile GCC
> (that will be run on powerpc64le and produce binaries
> for powerpc64le) or are you trying to build a cross-compiler
> (that will be run on x86_64 and produce binaries for powerpc64le)?
> 
> This command does the former.

That’s a great question. I hadn’t noticed this subtlety. What I’m actually 
trying to do is reproduce this CI failure on core-updates:

https://ci.guix.gnu.org/build/667452/details

Looking at the log file, I see this:

```
make[2]: Entering directory '/tmp/guix-build-gcc-11.1.0.drv-0/build/gcc'
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... powerpc64le-unknown-linux-gnu
checking target system type... powerpc64le-unknown-linux-gnu
```

So by luck I’m doing what I needed to do, which is cross-compile a GCC for 
a powerpc64le host and powerpc64le target.

> > on current core-updates branch (commit 8456581375cf), I get the
> 
> > following error during the build of glibc-mesboot-2.16:
> Why is 'glibc-mesboot-2.16' being cross-compiled here?
> Mesboot currently only supported i686-linux and x86_64-linux and
> not powerpc64le-linux (at least the version currently in Guix).

I don’t know why my system tried to build it. Perhaps because of the bogus 
target string. When I used the correct one I had to use the `guix build -e 
(@@ …)` trick to force the build again. I’ll try again to be sure, but if 
that is the case then this patch can be dropped.

> > I deduced that this is because `(assoc-ref inputs "libc")` is returning
> > #f. And indeed, changing the code to look in %build-inputs instead
> > fixes the issue. I also noticed that most other places which look for
> > a "libc" package do so in %build-inputs rather than in inputs.
> > 
> > Just changing the line for "libc" is enough to fix the build but for
> > consistency, also change the other variables as well.
> 
> Normally, looking up inputs in 'inputs' is the right thing,
> but 'libc' is special. Looking at 'standard-cross-packages',
> it seems like when cross-compiling, "libc" is renamed to "cross-libc",
> for no apparent reason.  Maybe it can be renamed back to "libc"?
> 
> That could simplify some code, e.g. in qtbase-5:
> 
>              (let ((glibc (assoc-ref inputs ,(if (%current-target-system)
> "cross-libc" "libc"))))
> 
> would become:
> 
>              (let ((glibc (assoc-ref inputs "cross-libc")))
> 
> If I search with git grep '"cross-libc" "libc", I find 5 such examples.

Sorry, I don’t know about that but I can poke around to see if I can find 
something out.

> Are you sure your usage of (assoc-ref %build-inputs "libc") is correct
> here?

I’m not, to be honest. I’m still familiarizing myself with gexps.

> 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.

-- 
Thanks,
Thiago