This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is fixinclude needed on modern systems?


Ian Lance Taylor wrote:
NightStrike <nightstrike@gmail.com> 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....





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]