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

[Mathieu Othacehe]

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