Brian Dessent wrote:
By the time you have a working cross-binutils and cross-gcc getting the
target libraries cross compiled should be pretty simple, assuming that
you've copied over the system headers into $prefix/$target/include and
startup objects into $prefix/$target/lib.
Please define "system headers"! The obvious assumption is that the
"system headers"
will go into the '$prefix/$target/sys-include' meanwhile the "standard
headers" (those
usually in '/usr/include' natively) will go into the
'$prefix/$target/include'. A cross-GCC
has always places for both types of headers although only some few
systems have any
"system headers" in their native GCCs... Whether AIX has these is
unclear, BeOS and
Mach at least once had the SYSTEM_INCLUDE_DIR defined for them....
The very well-known bug in the GCC sources has been that during the GCC
build the
place aimed for the "system headers", the 'sys-include', is where the
"standard headers"
are expected to be for "fixinc" and existence checks! The "GCC
Internals" manual says
in:
http://gcc.gnu.org/onlinedocs/gccint/Header-Dirs.html#Header-Dirs
about these things totally differently :-( It is really surprising
that this kind of clash between
the GCC documentation and what the GCC build really does, can have been
"maintained"
years and years....
The work-arounds for this bug have been to use the '--with-headers='
which copies the
pointed headers into 'sys-include' (people are assumed to be not capable
to use even 'cp'?),
or make a 'sys-include' symlink to point to the 'include' where the
target standard headers
are preinstalled (some people can even be capable to make symlinks)....
Generally if the 'fixinc' succeeds in a native build, it should also
succeed in cross build! If
only those standard headers are seen also as "system headers" (whatever
they then are)....
The problems have been with the GCC targets which don't have "native"
GCCs for them
at all, trying to "fix the already fixed" C library headers made for
only GCC, like those
in 'newlib', has many times been a fiasco, the fixing for instance
removing all spaces from
some originally working headers.... So all kind of theories about the
"sys-include bug" being
a way for the builder to choose whether the target headers should or
shouldn't be "fixed"
for GCC, have floated around this so weird thing in the cross-GCC build....
