[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mathieu Othacehe
Subject: bug#36882: Qemu 4.2.0 build for x86_64-linux fails
Date: Tue, 25 Feb 2020 15:46:15 +0100
User-agent: mu4e 1.2.0; emacs 26.3

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 
                 from test.c:1:
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

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 :),


reply via email to

[Prev in Thread] Current Thread [Next in Thread]