This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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: Tutorial 4


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


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