This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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: gcc3.1 cross won't find feature_tests.h (and yes, feature_tests.h is just sitting there)


miki.shapiro@eAladdin.com wrote:
> 
> Hi, I'm trying to compile gcc3.1 on a SPARC/Solaris8 host that will produce
> SPARC/Solaris7 binaries.
> 
> --with-headers=/usr/src/cross-sparc-sun-solaris2.7/sol7/include
> --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:
> /usr/share/src/cross-sparc-sun-solaris2.7/gcc-3.1/build/gcc/xgcc
> -B/usr/share/src/cross-sparc-sun-solaris2.7/gcc-3.1/build/gcc/
> -B/usr/local/sparc-sun-solaris2.7/bin/
> -B/usr/local/sparc-sun-solaris2.7/lib/
> -isystem /usr/local/sparc-sun-solaris2.7/include  <---------- !!!!!
> -DIN_GCC -DCROSS_COMPILE   -W -Wall

 (Your output was a little rearranged...)

> /usr/share/src/cross-sparc-sun-solaris2.7/gcc-3.1/build/gcc/include/stdio.h:36:31:
> sys/feature_tests.h: No such file or directory
> /usr/share/src/cross-sparc-sun-solaris2.7/gcc-3.1/build/gcc/include/stdio.h:37:25:
> sys/va_list.h: No such file or directory
> /usr/share/src/cross-sparc-sun-solaris2.7/gcc-3.1/build/gcc/include/stdio.h:39:24:
> 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) :

H:\usr\local\lib\gcc-lib\sparc-solaris2.7\2_95.3-1>cpp0 -v
GNU CPP version 2.95.3-1 20010315 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
 \usr\local\lib\gcc-lib\sparc-solaris2.7\2_95.3-1\..\..\..\..\include
 \usr\local\lib\gcc-lib\sparc-solaris2.7\2_95.3-1\include
 \usr\local\lib\gcc-lib\sparc-solaris2.7\2_95.3-1\..\..\..\..\sparc-solaris2.7\include
End of search list.
The following default directories have been omitted from the search path:
 /usr/local/lib/gcc-lib/sparc-solaris2.7/2_95.3-1/../../../../include/g++-3
 /usr/local/lib/gcc-lib/sparc-solaris2.7/2_95.3-1/../../../../sparc-solaris2.7/sys-include
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...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


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