m68k-rtems-gcc toolchain build problem on Solaris-7
Ralf Corsepius
corsepiu at faw.uni-ulm.de
Tue Dec 30 18:01:35 UTC 2003
Some remarks interspersed ...
FWIW: I recall having seen this error before, ... unfortunately I don't
recall the cause :( (It's been a while since I had built gcc-3.2.3 the
last time.)
On Tue, 2003-12-30 at 09:20, Paul Cadaret wrote:
> to run the build according to the PDF file at
> http://www.rtems.com/onlinedocs/releases/rtemsdocs-4.6.0pre5/share/rtems/pdf/started.pdf
> and I followed the PDF file instructions carefully for:
>
> 4.1.2 Unarchiving the Tools
> 4.1.3 Applying RTEMS Patches,
> Apply RTEMS Patch to GCC,
> Apply RTEMS Patch to binutils,
> Apply RTEMS Patch to newlib
> 4.1.4.2 Using configure and make,
> Configuring and Building BINUTILS,
> Configuring and Building GCC and NEWLIB
>
> Binutils built and installed without error.
Is /tools/local.m68k-rtems/bin in $PATH when configuring and building gcc?
Is /tools/local.m68k-rtems/bin at the beginning of $PATH?
Which shell are you using? gcc-3.2.3 is rumored to require bash or
another sufficiently POSIX compliant sh (Solaris /bin/sh is known not to
be sufficient, some versions of pdksh are known to be broken; Newer
ksh's should work, older ones are broken; /usr/xpg4/bin/sh should work)
Which options exactly do you pass to gcc's configure?
It should be something similar to this:
export PATH="/tools/local.m68k-rtems/bin:${PATH}"
../gcc-3.2.3/configure \
--target=m68k-rtems \
--with-gnu-as --with-gnu-ld --with-newlib --verbose \
--with-system-zlib --disable-nls \
--enable-version-specific-runtime-libs \
--enable-threads=rtems --prefix=/tools/local.m68k-rtems
--enable-languages="c,c++"
[Building on Solaris might require not use --with-system-zlib, ie. to
build zlib.]
> Building gcc-3.2.3 died as follows:
>
> /sd/c0t8d0/opt1/web/sites/ftp.rtems.com/tools/gcc-3.2.3/build.m68k-rtems/gcc/xgcc
> -B/sd/c0t8d0/opt1/web/sites/ftp.rtems.com/
> 1114 tools/gcc-3.2.3/build.m68k-rtems/gcc/ -nostdinc
>
> -B/sd/c0t8d0/opt1/web/sites/ftp.rtems.com/tools/gcc-3.2.3/build.m68k-rtems/m
> 1114 68k-rtems/newlib/ -isystem
>
> /sd/c0t8d0/opt1/web/sites/ftp.rtems.com/tools/gcc-3.2.3/build.m68k-rtems/m68k-rtems/newlib/targ-i
> 1114 nclude -isystem
>
> /sd/c0t8d0/opt1/web/sites/ftp.rtems.com/tools/gcc-3.2.3/src/newlib/libc/include
> -B/tools/local.m68k-rtems/m6
> 1114 8k-rtems/bin/ -B/tools/local.m68k-rtems/m68k-rtems/lib/
> -isystem /tools/local.m68k-rtems/m68k-rtems/include -O2 -I../../src/
> 1114 gcc/../newlib/libc/sys/rtems/include -DIN_GCC
> -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-proto
> 1114 types -isystem ./include -g -DHAVE_GTHR_DEFAULT
> -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I.
> -I../../src/g
> 1114 cc -I../../src/gcc/. -I../../src/gcc/config
> -I../../src/gcc/../include -DL_fixunsdfsi -c
> ../../src/gcc/libgcc2.c -o libgcc/
> 1114 ./_fixunsdfsi.o
>
> 1115 In file included from
>
> /sd/c0t8d0/opt1/web/sites/ftp.rtems.com/tools/gcc-3.2.3/build.m68k-rtems/gcc/include/syslimits.h:7,
> 1116 from
>
> /sd/c0t8d0/opt1/web/sites/ftp.rtems.com/tools/gcc-3.2.3/build.m68k-rtems/gcc/include/limits.h:11,
> 1117 from ../../src/gcc/libgcc2.c:1166:
> 1118
>
> /sd/c0t8d0/opt1/web/sites/ftp.rtems.com/tools/gcc-3.2.3/build.m68k-rtems/gcc/include/limits.h:132:75:
> no include path in whi
> 1118 ch to find limits.h
> 1119 make[2]: *** [libgcc/./_fixunsdfsi.o] Error 1
> 1120 make[2]: Leaving directory
Some wild guesses on general gcc-building issues, I had encountered
building different gcc versions:
* Make sure $prefix/m68k-rtems exists before building.
mkdir -p /tools/local.m68k-rtems/m68k-rtems
* After having run configure, try this
cd <builddir>
test -d gcc/include || mkdir -p gcc/include
cp ../gcc-3.2.3/gcc/gsyslimits.h gcc/include/syslimits.h
* Make sure not to have set *any* environment variables that might
interfere with gcc (CPP, LIB, LIBS, CC, CFLAGS, CXXFLAGS etc.)
* Make sure not to have '.' in $PATH.
* Do not try to relocate gcc. Install it to the prefix it had been
configured for.
> What is "the system's own limits.h file" ??? linux? solaris? newlib?
> rtems?
The target's limits.h, which should have been generated when building
the target gcc.
> The "#include_next" is a feature of the newer gcc's
IIRC, #include_next is in gcc for a very long time ... (IIRC gcc-2.7.x
if not earlier).
Anyway, it is xgcc, the just "having been built cross-compiler", which
chokes, not your native gcc.
[..]
> Since 'configure' builds the makefiles here and I have no idea what it
> is trying to accomplish here, I really don't know
> what to fix.
> As best I can tell the Solaris toolchain is broken.
Well, yes, sparc-sun-solaris-gcc is troublesome and in most cases
requires additional patching, but .. AFAIS, this is not the cause of
your issue.
(BTW: Building gcc-3.x for Solaris2.7 requires using
--target=sparc-sun-solaris2.7; sparc-sun-solaris is similar, but not
identical to sparc-sun-solaris2.7)
However, this should not matter here. You are building for
--target=m68k-rtems.
The fact xgcc already has been built at the stage you are seeing the
error indicates your solaris-gcc to be functional.
=> The cause of the breakdown is somewhere else.
> Some further data:
>
> rtems> uname -a
> SunOS u2 5.7 Generic_106541-08 sun4u sparc SUNW,UltraSPARC-IIi-Engine
>
> rtems> perl --version
> This is perl, v5.6.0 built for sun4-solaris
> rtems> autoconf --version
> autoconf (GNU Autoconf) 2.59
>
> rtems> automake --version
> automake (GNU automake) 1.8
FWIW: The autotools are not used when building gcc.
> rtems> gmake --version
> GNU Make 3.80
>
> rtems> gcc --version
> 2.95.2
>
> rtems> type m68k-rtems-as
> m68k-rtems-as is /tools/local.m68k-rtems/bin/m68k-rtems-as
>
> rtems> m68k-rtems-as --version
> GNU assembler 2.13.2.1
Ralf
More information about the users
mailing list