Matt Harrington wrote:
I don't fully understand what gcc is doing during its build process.
Be sure that anyone who has built GCCs longer than 10 years neither
understands the "features" (in the worst MS-like meaning) in the GCC
build process :-(
Is the idea that it is trying to make the headers more compliant with
> itself or with standards in general? I had originaly put the headers
> nto sys-include because the build process was asking for libc headers.
> Am I missing an earlier step here?
The GCC manuals used to tell that the target headers should be put into
the '$(tooldir)/include', for instance the gcc-3.4 manual(s) in the
chapter "Standard Header File Directories" ("GCC Internals"):
"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)."
but since 1995 or something this directory has instead been the
‘$(tooldir)/sys-include’, the GCC build expects the standard target
headers ('stdio.h', 'stdlib.h', 'limits.h', 'time.h',...) being there,
although this directory seems originally been aimed for the target
system (specific) headers like the kernel headers in Linux, the GUI
headers (Win32API,...) etc. headers which may be present only in this
specific target system. A native GCC can have it's own 'sys-include'
defined via the :
SYSTEM_INCLUDE_DIR [Macro]
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.
and so the ‘$(tooldir)/sys-include’ is the place where these (usually
non-existing) target system headers should be put from the native GCC's
SYSTEM_INCLUDE_DIR. The STANDARD_INCLUDE_DIR is usually the native
'/usr/include' and it's equivalent in a cross-GCC is the directory
‘$(tooldir)/include’.
So my reply was very provocating... Expecting people to know these
basic things about headers and libraries and wondering why there are
two places for the target headers in a cross-GCC when a native GCC
usually has only one, and that a 'include' in a cross GCC sounds more
natural place as the equivalent place to the native 'include', not
the 'sys-include', I really have expected people to ask about these
two all the time. And escpecially why the GCC build rules clash so
badly with the manuals...
Never any sane explanations seen for this mess but anyway the rules
are :
o the headers put into the ‘$(tooldir)/sys-include’ via using the
'--with-headers=' configure option or manually pre-installing
them there, will be seen and tried to be fixed by the GCC build.
The new "Install" instructions suggest people to use the
'--with-headers=' option. Or use the '--with-sysroot=' in the
'system' target cases, those which have native GCCs as their
default GCCs, not cross GCCs (which means there being nothing
like native GCCs for these 'embedded' targets).
o the headers put into the ‘$(tooldir)/include’ will be 'hided' from
the GCC build, so they will neither be seen, nor tried to be fixed.
The produced cross-GCC ('xgcc' etc. binaries) of course finds these
headers but the GCC build scripts don't...
However some standard headers seem to be obligatory to be seen in the
'sys-include', the 'limits.h' (if it exists), 'stdio.h', 'stdlib.h',
'string.h', 'time.h' and 'unistd.h'. Otherwise the GCC build tries to
use some non-working stubs, dummy stripped replacements from its own
repertoire...
Very complicated but in all this mess there MUST be some sanity
otherwise this mess would be fixed years ago... People like me are
just too stupid to see this wisdom, this is my conclusion. Knowing
WHAT one must do is enough, not WHY that must be done. Guys like
"Sinuhe the Egyptian" and me simply seem to think too much...
These headers in question are used with a modified version of gcc 2.95
which is already configured for cross compiling so I would expect them to
be "good enough" the way they are. What should I be doing differently
here?
Despite of all the previous, there still can be some sanity in some
things the 'fixincludes' does. But one must check what it really did
and whether that was sane at all! The fixed headers go into the
'$build/gcc/include' and can then be compared via 'diff -c' with the
originals, looking at the changes made. And then manually fixing the
automatically fixed headers or simply removing some of them...
Or one can think that the originals are good enough and don't need
any fixing, if this will be required the GCC build would crash with
the nonfixed things. An example could be the glibc-2.2.x headers with
their '__thread' used as a parameter name in some protos when newer
GCCs use this as a type name. Who could expect the GNU C library
headers requiring 'fixing' for the GNU C compiler? Putting the target
headers to their 'de facto' place, ‘$(tooldir)/include’, hides them
from all fixing. Only those six 'obligatory' target headers should be
put into the ‘$(tooldir)/sys-include’. This is the method I have used.
If the header fixing changes something in them, there are only six
known headers to check...
The VxWorks target case can be quite unclear, but some things I do
remember from the past years :
o the target headers have the C and C++ headers mixed in a mess and
somehow one should try to remove the C++ ones (the gcc-2.95 ones
in your case), putting them among the C ones sounds really weird
when the default GCC install puts them always separated from the
standard C headers.
o newer PPC family CPUs are not necessarily recognized by the VxWorks
headers or in the VxWorks config headers in 'gcc/config/rs6000', so
using some '--with-cpu=<something>' in the GCC configure can cause
the build to crash with the not understood CPU type...
Using Google and searching with "powerpc-wrs-vxworks" gave as the first
hit the:
http://sources.redhat.com/ml/crossgcc/2002-04/msg00034.html
to which I seem to have answered in 2002... Maybe it would be best to
read those discussions found via this key word, I really don't know
much about VxWorks/PPC itself.
powerpc-wrs-vxworks
