bug#36882: Qemu 4.2.0 build for x86_64-linux fails

[Mathieu Othacehe]

Oops wrong shortcut, sorry!

> I’d rather go for #2.  To do that, we could modify the ‘set-paths’ phase
> to manually remove glibc from C_INCLUDE_PATH (fragile), or we could
> modify GCC (perhaps removing the ‘remove_duplicates’ call for SYSTEM).
>
> Either way, this wouldn’t work well with ‘guix environment’, where glibc
> ends up in /gnu/store/…-profile, so it does not appear as duplicate to
> GCC.

[...]

> Looking at ‘cppdefault.c’ in GCC, I don’t see where glibc-2.31/include
> comes from; it seems that ‘INCLUDE_DEFAULTS’ is undefined on glibc
> systems.

It's indeed undefined and glibc comes from NATIVE_SYSTEM_HEADER_DIR at
the end of the file you mentioned. It is a consequence of passing
--with-native-system-header-dir=glibc in (gnu packages gcc).

About the environment issue, we have the same problem on master. You can
run the following command:

--8<---------------cut here---------------start------------->8---
 ./pre-inst-env guix environment -C -e '(@@ (gnu packages commencement)
 coreutils-final)' -- echo -e '#include <stdint.h>\n int main() {return
 0;}' > test.c && gcc -m16 -ffreestanding test.c
--8<---------------cut here---------------end--------------->8---

and see that in takes stdint.h from the profile glibc header:

--8<---------------cut here---------------start------------->8---
In file included from 
/gnu/store/nl6zndkx4115laq50qmqcvnzinfz5rk0-profile/include/features.h:474:0,
                 from 
/gnu/store/nl6zndkx4115laq50qmqcvnzinfz5rk0-profile/include/bits/libc-header-start.h:33,
                 from 
/gnu/store/nl6zndkx4115laq50qmqcvnzinfz5rk0-profile/include/stdint.h:26,
                 from test.c:1:
/gnu/store/nl6zndkx4115laq50qmqcvnzinfz5rk0-profile/include/gnu/stubs.h:7:11: 
fatal error: gnu/stubs-32.h: No such file or directory
 # include <gnu/stubs-32.h>
           ^~~~~~~~~~~~~~~~
--8<---------------cut here---------------end--------------->8---

So if it's ok for you, I'll try to implement a GCC hack so that we can
keep using C_INCLUDE_PATH on core-updates and have QEMU building, as you
proposed.

About the environment use-case, it's getting really tricky, but as it is
not a regression, we can maybe postpone the resolution.

> Incidentally, do we have problems building anything other than QEMU?

I don't know, but potentially any program building with -m<something>
and -ffreestanding fails on core-updates.

Thanks for your help :),

Mathieu