gcc errror with current glibc

[H. Peter Anvin]

On 2025-07-15 05:26, Adhemerval Zanella Netto wrote:
>>
>> The installed version of glibc was
>> glibc-2.41.9000-486-g632d895f3e and the same gcc
>> was installed without error with it.
>>
>> So I assume this bug(?) appeared somewhere since then.
>> Please cc me.
> 
> We are discussing this [1] issue, sanitizer are relying on some definitions
> that were exported by glibc and removed recently.
> 
> [1] https://sourceware.org/pipermail/libc-alpha/2025-July/168626.html
 >

So, ioctl is a low-level kernel interface.  In Linux, that is provided 
by the <linux/*> headers, not by the glibc ones.  Some <linux/*> 
headers, notably <linux/termios.h>, conflict with the glibc ones.  The 
best solution would be to factor out the ioctl harvesting on Linux into 
a separate compilation unit and include only the absolute minimum of 
libc(++) headers.

strace (https://github.com/strace/strace) has an even more extensive 
system (with some hand-coded exceptions, too) for harvesting ioctl 
information from Linux; in some ways this would be an even better approach.

There are, on Linux, exactly four ioctls which are provided by ioctl(3) 
but not by ioctl(2), and only on the PowerPC platform.  They are 
alternate versions of TCGETS, TCSETS, TCSETSW, and TCSETSF; the kernel 
versions are supported as well (they have different numbers because the 
number encodes the size of the structure, which is different between the 
kernel and libc versions.)

In the short term, I posted a simpler fix from when this first crept up.

	-hpa