Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt

[Matthias Klose <doko@debian.org>]

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 ...