On 3/4/20 9:48 AM, Florian Weimer wrote: > * Matthias Klose: > >> On 3/4/20 9:33 AM, Florian Weimer wrote: >>> * Matthias Klose: >>> >>>> The __glibc_has_include macro needs to be restored until GCC is rebuilt. At >>>> least on s390x, you get a non-wrorking compiler, which at least cannot >>>> glibc >>>> anymore. The macro is still referenced in the include-fixed directory. >>>> >>>> Seen with the 2.31 branch, but I see that this is also backported to 2.30. >>> >>> This is a bug in the gcc package. It must not run fixincludes, to >>> avoid producing mutually incompatible headers because only a subset of >>> them is rewritten. >> >> Is this something which should be done upstream? Or just don't include any >> fixed header in the GCC packages? > > Distributions should never run fixincludes for this reason. This is a > hack for installing compilers as non-root on proprietary systems, > where you can't fix the headers. > > Other distributions routinely backport compiler compatibility fixes > into glibc (even into stable releases), and I think this is the way it > has to be done. > >> Anyway, either glibc or GCC has to be fixed to avoid a non-working compiler. > > If I recall correctly, the header is broken anyway because linux is > rewritten into __linux__, due to a fixincludes bug. > > It should be possible to hide the header by having a file with an > #include directive with an absolute path in a directory used during > the build.
ok, now removing that leads to: $ cat foo.c #include <limits.h> $ gcc -c foo.c In file included from foo.c:1: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h 124 | # include_next <limits.h> | ^ wondering if other distros patch glibc for that ...