Ian Lance Taylor wrote:
NightStrike <nightstrike@xxxxxxxxx> writes:
What does fixincludes actually do?
It is essentially a large sed script which edits the system header
files so that they work correctly with gcc.
This naturally then leads to the question about what those mystical "system
header files" are? They cannot be the "standard header files", usually
in the
'/usr/include' and for which directory the :
http://gcc.gnu.org/onlinedocs/gccint/Driver.html#Driver
uses the macro name 'STANDARD_INCLUDE_DIR'. Seemingly they are
those headers in "a system-specific directory to search for header files
before
the standard directory", for which the GCC Internals uses the macro name
'SYSTEM_INCLUDE_DIR' . When the GCC build nowadays tries to fix the
headers in the '$tooldir/sys-include' when producing a crosscompiler and
this
is the equivalent to the native SYSTEM_INCLUDE_DIR, that those "system
header files" are something which a native system very seldom has, is a
quite
obvious conclusion! And that 'fixincludes' will be required only once
in ten
years or so when there really are some system headers to fix....
But we all know that the stuff in '/usr/include' will be tried to be
fixed during a
native GCC build and that the GCC manual says in :
http://gcc.gnu.org/onlinedocs/gccint/Header-Dirs.html#Header-Dirs
the following "fact" :
"A cross compiled GCC runs |fixincludes| on the header files in
$(tooldir)/include.
(If the cross compilation header files need to be fixed, they must be
installed
before GCC is built. If the cross compilation header files are already
suitable
for GCC, nothing special need be done)."
ie. the "standard header files" in '$tooldir/include' will be handled
during a cross GCC
build...
So there is no evidence for the "system header files" being tried to be
fixed but
that the "standard header files" should be tried to be fixed via
'fixincludes' ! This
means handling (usually) the '/usr/include' during a native build and
handling the
'$tooldir/include' during a cross GCC build.... Sounds quite simple !
The big mystery which remains, therefore is: How on earth someone could
ever
mix the standard headers and system headers and still imagine them being
just the
same thing? And not know that the '$tooldir/include' is the place where
the target
headers are/should be put in a crosscompiler?
Quoting the current 'gcc-4.1.2/gcc/Makefile.in' :
# Default native SYSTEM_HEADER_DIR, to be overridden by targets.
NATIVE_SYSTEM_HEADER_DIR = /usr/include
# Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@
Instead of talking about 'STANDARD' headers, someone has started to use the
name 'SYSTEM'... And there is always a place for "system headers" in a
cross
GCC, so when the question is about system headers, naturally this
CROSS_SYSTEM_HEADER_DIR is defined to be the '$tooldir/sys-include'
in the configure system....
Does someone really see any sanity in what 'fixincludes' does during a
cross
GCC build? I only see a big mess in this :-( If not that "code red"
convention
from Gitmo (new recruits teached to accept all kind of insane things as
the "army
rules"). A typical GCC builder with a newlib-using target will be
forced to know
very well this "feature", to become aware to empty the 'sys-include'
after the
GCC build if there were any non-final headers, the newlib install will
put the final
headers to the 'include' but the 'sys-include' will be searched before
it... And so
on....
