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
