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] |
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] |