gcc3.1 cross won't find feature_tests.h (and yes, feature_tests.h is just sitting there)
Thu Jun 6 06:01:00 GMT 2002
> Hi, I'm trying to compile gcc3.1 on a SPARC/Solaris8 host that will produce
> SPARC/Solaris7 binaries.
> --with-libs=/usr/src/cross-sparc-sun-solaris2.7/sol7/lib --with-gnu-as
> --with-gnu-ld --with-gnu-ar
> (I copied headers and libraries from a SPARC/Solaris7 machine to
> /usr/src/cross-sparc-sun-solaris2.7/sol7 on this box. Yes, I know I can
> copy them directly to the destination in
> /usr/local/sparc-sun-solaris2.7/lib and
> /usr/local/sparc-sun-solaris2.7/sys-include subdirectories. I like doing it
> like this :-) ).
Wherever you got the instructions for using the --with-headers=' or
preinstalling the headers into '/usr/local/sparc-sun-solaris2.7/sys-include',
they clash with what the GCC-build does now :
> During compilation, I get the following:
> -isystem /usr/local/sparc-sun-solaris2.7/include <---------- !!!!!
> -DIN_GCC -DCROSS_COMPILE -W -Wall
(Your output was a little rearranged...)
> sys/feature_tests.h: No such file or directory
> sys/va_list.h: No such file or directory
> stdio_impl.h: No such file or directory
So there is a hack now to find the 'include', not the 'sys-include'. However the
'sys-include' should be found via the '../../../../sparc-sun-solaris2.7/sys-include',
if the '/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/3.1' already exists. If not,
it will not be found... The 'install_dir' should be created during the GCC-build in
gcc-3.1, but perhaps it happens after the phase you got your errors. Creating it
manually is the obvious workaround and this workaround was very common with gcc-2.95.2...
You can look with the './cpp0 -B./ -v' in your '$build/gcc' what the search paths
for headers now are. The output should be something like (here on Windoze) :
GNU CPP version 2.95.3-1 20010315 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
End of search list.
The following default directories have been omitted from the search path:
End of omitted list.
The output should tell WHY it now doesn't find the headers.
I have never trusted the 'fixincludes' in the 'header fixing', the gcc-3.1 prereleases
and the current gcc-3.1.1 prereleases simply spoil some newlib-headers (signal.h and
time.h) if fixincludes is allowed to 'fix' the headers. I would assume gcc-3.1 doing the
same... Don't know what good or bad it now does with the Solaris2 headers.
So my advice would be to put the unfixed headers into the de-facto standard
'$prefix/$target/include', then copy the 'math.h' and 'limits.h' into the weird
new suggestion, '$prefix/$target/sys-include', where fixincludes etc. will find
them, but 'xgcc' will find all the headers with its '-isystem' option...
But when you now have those 'fixincludes'-fixed headers, checking what on earth the
'fixing' did to them is more than sane... I would expect quite a lot 'sparc'-to-'__sparc__'
ANSI/ISO-nonsense (?), maybe some stupid double '#ifndef HUGE'-wrappings etc., but
hopefully not any totally spoiled headers a'la newlib...
Generally all this 'include' versus 'sys-include' has been a mess for a long time and
the GCC-community has behaved like M$ by denying any bug existing, it is only a 'feature'
which cannot be fixed, sigh...
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to email@example.com
More information about the crossgcc