On 2/4/22 14:30, Jakub Jelinek via Gcc-patches wrote:
On Fri, Feb 04, 2022 at 02:25:17PM +0100, Richard Biener via Gcc-patches wrote:
Besides, have you actually run a regtest with that option? I'm asking
because even on Ubuntu 20.04 fixincludes drops in it's own <limits.h>.
You need to check that dropping that is actually safe.
limits.h and syslimits.h are the only include-fixed we "ship" in our
packages. Not sure if they are really required though.
We don't ship any include-fixed headers in Fedora/RHEL.
If there is an important need for fixing, it should be in Linux
distributions fixed by actually fixing the headers in their corresponding
packages, making modified copies of headers at gcc build time and overriding
through that headers from other packages that can change doesn't really work
properly when those headers ever change. I know we could install the
fixincludes tool and trigger running it whenever any of such headers change
in other packages, but that is very expensive for very little gain.
I fully agree with the suggested approach! I've also noticed the script makes
modifications in comments (that are unnecessary), plus it effectively breaks
header files for things like:
$ diff /usr/lib64/gcc/aarch64-suse-linux/11/include-fixed/bits/unistd_ext.h
/usr/aarch64-suse-linux/sys-root/usr/include/bits/unistd_ext.h
46c37
< # if __has_include ("__linux__/close_range.h")
---
# if __has_include ("linux/close_range.h")
I would suggest removing the fixed includes in openSUSE as well?
Martin
On other targets I understand fixincludes is much more important.
Jakub
