a question about fix-header.c

[Kai Ruottu]

Zack Weinberg wrote:

> You should not be solving this problem by editing system headers.

  There has been a mess for years with cross-GCCs because of handling
the "standard headers", weirdly some people thinking these being the
same thing as "system headers". The "GCC Internals" for gcc-3.4 however
tells that these are two different things :

-------------------- clip ---------------------------
SYSTEM_INCLUDE_DIR
  Define this macro as a C string constant if you wish to specify a
  system-specific directory to search for header files before the standard
  directory. SYSTEM_INCLUDE_DIR comes before STANDARD_INCLUDE_DIR in the
  search order.

  Cross compilers do not use this macro and do not search the directory
  specified.

STANDARD_INCLUDE_DIR
  Define this macro as a C string constant if you wish to override the
  standard choice of `/usr/include' as the default prefix to try when
  searching for header files.

  Cross compilers ignore this macro and do not search either `/usr/include'
  or its replacement.
-------------------- clip ---------------------------

  A cross-GCC doesn't use these macros but has equivalents for these two
native header places, '$prefix/$target/sys-include' for the first and
'$prefix/$target/include' for the second. A native GCC usually has no
place defined for "system headers" and uses only the "standard headers" in
'/usr/include'. The '$prefix/$target/sys-include' should therefore be
unused unless the native equivalent has those "system headers". Targets
(or native hosts) like BeOS and Mach have GUI and non-posix headers as
"system headers", but Windoze ports, Cygwin and MinGW, could also handle
the Win32 API headers as "system headers" but surprisingly they don't and
don't define SYSTEM_INCLUDE_DIR for the native Cygwin and MinGW GCCs...

About the 'sys-include' and the 'include' the "GCC Internals" tells :

-------------------- clip ---------------------------
CROSS_INCLUDE_DIR is used only by cross compilers. GCC doesn't install anything
there.

TOOL_INCLUDE_DIR is used for both native and cross compilers. It is the place
for other packages to install header files that GCC will use. For a
cross-compiler, this is the equivalent of `/usr/include'. When you build a
cross-compiler, fixincludes processes any header files in this directory.
-------------------- clip ---------------------------

and earlier also about the header-fixing in a crosscompiler build:

-------------------- clip ---------------------------
GCC_INCLUDE_DIR means the same thing for native and cross. It is where GCC
stores its private include files, and also where GCC stores the fixed include
files. A cross compiled GCC runs fixincludes on the header files in
`$(tooldir)/include'.
-------------------- clip ---------------------------

So everything looks fine what becomes to the GCC manuals (forgetting the
"Install" one which seems to be written partly with newbies...). People know
what are the 'standard headers' usually in '/usr/include' in a native compiler
and copied to the '$prefix/$target/include' in a crosscompiler. And that those
'system headers' are something which doesn't usually exist and if existing,
only the 'standard headers' are tried to be fixed for GCC...

But why the GCC build tries to make a cross-GCC build into a big mess by
expecting at least some of the target's 'standard headers' seen in the
'$prefix/$target/sys-include' ?  Seeing the 'limits.h', 'stdio.h', 'stdlib.h',
'string.h', 'time.h' and 'unistd.h' there in the gcc-3.4 case seems to be
necessary.

Maybe the majority of possible GCC targets don't know about 'native GCCs' for
them, only cross GCCs, so this mess hurts the most targets.  Fixing the headers
in a native GCC build seemingly hasn't any problems coming from some wacky
misunderstanding, like trying to fix headers from '/usr/sys-include'...

The available free C libraries like newlib and glibc don't install anything into
the 'sys-include', putting their 'standard headers' always into the 'include' in
their install phases.

So my wish could be that whoever changed the 'fixincludes' situation with cross
GCCs, by putting the GCC build to search the standard target headers from the
'sys-include' instead of the expected and documented 'include', could change the
situation back to follow the GCC manuals !  I have changed my local sources and
know that this isn't very hard.  If this was intentional, trying to make a cross
GCC build as hard as possible and that way helping GCC consultants to get more
money, then there could be some sanity, otherwise not... Unfortunately most GCC
builders only try to get no cost help with these things, so getting things
harder hasn't achieved its goal :(

BTW, the CROSS_INCLUDE_DIR and TOOL_INCLUDE_DIR are not very good names for the
places, better names could be for instance SYS_INCLUDE_DIR and STD_INCLUDE_DIR
and a native GCC using the SYS_INCLUDE_DIR instead of the other "for other
packages to install header files that GCC will use". Then all the new C++ header
directories are still undocumented, what on earth for is the PREFIX_INCLUDE_DIR,
$prefix/include', is it the common place for all cross-GCCs using the same
$prefix, how it differs from the LOCAL_INCLUDE_DIR when using the default
$prefix, '/usr/local'. There are quite a lot unclear things about the headers,
about their fixing and such...