This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Tutorial 4
- From: Peter Barada <pbarada at mail dot wm dot sps dot mot dot com>
- To: M_J_BUTCHER at compuserve dot com
- Cc: gcc at gcc dot gnu dot org, gcc-help at gcc dot gnu dot org
- Date: Wed, 26 Jun 2002 10:55:10 -0400
- Subject: Re: Tutorial 4
- References: <200206251849_MC3-1-3C8-3F1E@compuserve.com>
>- But something goes wrong in libstdc++ when trying to compile c++ sources
>as shown in this extract below
>
>/usr/local/src/gnu/gcc-3.1/newlib/libc/include -B/usr/local/mcore-elf/bin/
>-B/usr/local/mcore-elf/lib/ -isystem /usr/local/mcore-elf/include
>-I/usr/local/src/gnu/gcc-3.1/libstdc++-v3/../gcc
>-I/usr/local/src/gnu/gcc-3.1/libstdc++-v3/../include
>-I/usr/local/src/gnu/BUILD/gcc/mcore-elf/libstdc++-v3/include/mcore-elf
>-I/usr/local/src/gnu/BUILD/gcc/mcore-elf/libstdc++-v3/include
>-I/usr/local/src/gnu/gcc-3.1/libstdc++-v3/libsupc++ -g -O2
>-fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline
>-fdiagnostics-show-location=once -g -c
>/usr/local/src/gnu/gcc-3.1/libstdc++-v3/libsupc++/eh_alloc.cc -o eh_alloc.o
>In file included from
>/usr/local/src/gnu/gcc-3.1/libstdc++-v3/libsupc++/eh_alloc.cc:34:
>/usr/local/src/gnu/BUILD/gcc/mcore-elf/libstdc++-v3/include/cstdlib:86:
>`div_t'
> not declared
>
>I will try the build process with another target tomorrow (with build times
>of 8 hours on the home PC, experimentation is quite slow..)
>
>Any comments from the wise ??
I've seen the 'ldiv_t undeclared' problem more than once before:
http://gcc.gnu.org/ml/gcc/2002-02/msg00644.html
http://gcc.gnu.org/ml/gcc/2002-04/msg00908.html
What I have determined is that if a build failed for some reason,
executing a 'make clean ; make ; make install' for the particular
component doesn't always work since the 'make clean' doesn't remove
the *installed* components, or *all* of the config files, so when the
build occurs, it fails again in the same strange way.
What I have found that works is to:
1) remove *all* the installed components including binutils, gcc and newlib
2) remove *all* of the object directory structures where the tools were
built
3) rexecute the script which configures and builds the tools
This is the reason that I pick a directory to hole *everything*
installed by a particularly configured toolchain as well as a seperate
directory to hold all of the object directory structures. If an error
happens, I just blow away the object directory, the installed
directory, and start over. Fortunately for me it only takes 15
minutes to build it all over again on Linux.
In your case, you could just change PREFIX and remove
${SRC_ROOT}/BUILD and try again to see if it will complete.
Hope this helps...
--
Peter Barada Peter.Barada@motorola.com
Wizard 781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)