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