Hello,
> On master there’s pretty much the same command as above, with ‘-m16’, > and “yet it works”. > > https://ci.guix.gnu.org/log/ymzp5yz2r3zfw4xczwwlykyjv2kqcqs0-qemu-4.2.0 On master, when building qemu, this is the gcc include path (obtained with "gcc -v -x c -E /dev/null"): --8<---------------cut here---------------start------------->8--- /gnu/store/adm2cx3ayabn1sp84nnjsk0672m800ip-flex-2.6.4/include /gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6/include ... /gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include [1] /gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include-fixed /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/include [2] --8<---------------cut here---------------end--------------->8--- We see that glibc comes last. So when building a program with "gcc -ffreestanding -m16", the first <stdint.h> header picked is the one from gcc (marked [1] above). This header contains: --8<---------------cut here---------------start------------->8--- #ifndef _GCC_WRAP_STDINT_H #if __STDC_HOSTED__ <-- Set to 0 because of -ffreestanding option. # if defined __cplusplus && __cplusplus >= 201103L # undef __STDC_LIMIT_MACROS # define __STDC_LIMIT_MACROS # undef __STDC_CONSTANT_MACROS # define __STDC_CONSTANT_MACROS # endif # include_next <stdint.h> #else # include "stdint-gcc.h" <-- This one gets included. #endif #define _GCC_WRAP_STDINT_H #endif --8<---------------cut here---------------end--------------->8--- So the <stdint.h> from glibc (marked [2] above) is neved included. And that's good because this header would try to include <gnu/stubs-32.h> that our glibc does not provide. Now the question is, why glibc comes last, whereas it is a part of CPATH? The "gcc -v -x c -E /dev/null" command says: --8<---------------cut here---------------start------------->8--- ignoring duplicate directory "/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/include" as it is a non-system directory that duplicates a system directory --8<---------------cut here---------------end--------------->8--- So the glibc from CPATH is ignored and the last glibc, hardcoded into gcc is kept. Now, what's happening on core-updates? Because of CPATH -> C_INCLUDE_PATH transition, we have a different behaviour. The same command as above states: --8<---------------cut here---------------start------------->8--- ignoring duplicate directory "/gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include" ... /gnu/store/kyypmcn2miyzllqqmcx28gvj89qnvhpi-flex-2.6.4/include ... /gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include [1] ... /gnu/store/wl7zanqf0s9bfppggmv8qxqan71fjfw8-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/include [2] /gnu/store/wl7zanqf0s9bfppggmv8qxqan71fjfw8-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/include-fixed --8<---------------cut here---------------end--------------->8--- The glibc ignored seems to be the hardcoded one. The one from the C_INCLUDE_PATH is kept. So the <stdint.h> included is the one from glibc (marked [1] above), which triggers <gnu/stubs-32.h> inclusion and makes build fail. So here's how it fails, but I'm not sure how to fix it. Removing glibc from C_INCLUDE_PATH, forces gcc to use the hardcoded one that comes last and fixes the build. However, there are maybe other implications? Thanks, Mathieu
