Re: Re: building gcc toolchain for xscale-coff

[<vishu27 at cox dot net>]

Kai,
     I really appreciate your reply to my mail but I had already made the symlinks. These are the actual errors I get
/tmp/ccAevql2.s:13352: Error: branch out of range
/tmp/ccAevql2.s:14250: Warning: Failed to find real start of function: __ZNSt12strstreambufD1Ev

/tmp/ccAevql2.s:14250: Warning: Failed to find real start of function: __ZNSt9strstreamD0Ev

/tmp/ccAevql2.s:13514: Error: branch out of range
/tmp/ccAevql2.s:14250: Warning: Failed to find real start of function: __ZNSt12strstreambuf6freezeEb

/tmp/ccAevql2.s:14250: Warning: Failed to find real start of function: __ZNKSt12strstreambuf6pcountEv

/tmp/ccAevql2.s:14250: Warning: Failed to find real start of function: __ZNSt12strstreambuf3strEv

/tmp/ccAevql2.s:14250: Warning: Failed to find real start of function: __ZNSdD1Ev

/tmp/ccAevql2.s:14250: Warning: Failed to find real start of function: __ZNSdD0Ev

/tmp/ccAevql2.s:13352: Error: relocation overflow
/tmp/ccAevql2.s:13514: Error: relocation overflow
make[7]: *** [strstream.lo] Error 1
make[7]: Leaving directory `/nfs/iadusr02/vsankara/xscale-gnu/build-gcc/xscale-coff/thumb/libstdc++-v3/src'
make[6]: *** [all-recursive] Error 1
make[6]: Leaving directory `/nfs/iadusr02/vsankara/xscale-gnu/build-gcc/xscale-coff/thumb/libstdc++-v3'
make[5]: *** [all-recursive-am] Error 2
make[5]: Leaving directory `/nfs/iadusr02/vsankara/xscale-gnu/build-gcc/xscale-coff/thumb/libstdc++-v3'
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory `/nfs/iadusr02/vsankara/xscale-gnu/build-gcc/xscale-coff/libstdc++-v3'
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory `/nfs/iadusr02/vsankara/xscale-gnu/build-gcc/xscale-coff/libstdc++-v3'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/nfs/iadusr02/vsankara/xscale-gnu/build-gcc/xscale-coff/libstdc++-v3'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/nfs/iadusr02/vsankara/xscale-gnu/build-gcc/xscale-coff/libstdc++-v3'
make: *** [all-target-libstdc++-v3] Error 2

This is after building the boot strap gcc and building newlib and durinig the building of gcc for c++. I then tried your method stated as shown below

1. build binutils for the target using '--prefix=$prefix --target=$target' and
     install them
 2. copy the newlib headers for the target into $prefix/$target/include, they
    are in 'newlib-1.11.0/newlib/libc/include' in the current newlib
 3. set the symlinks to $prefix/$target/sys-include (those also Peter
     Barada told being required, ie. for the 'limits.h', 'stdlib.h' and 'unistd.h')
 4. configure GCC using '--with-newlib' and build for both C and C++
 5. build newlib with the installed GCC
 6. be happy

 So a GCC for a newlib-using target can be built when only the target
headers are installed, and the resulted GCC is the final one. For most
targets (with newlib) the generic newlib headers (step 2.) are the same
as the final, but for ARM/XScale the 'newlib/libc/sys/arm/sys/param.h'
should replace the generic 'sys/param.h', so two 'cp' commands may
be required in step 2.  Anyway no wacky 'bootstrap-GCC's and many
build iterations...


But I still get the same errors. I would appreciat it if you could let me know step by step what should be done.

Thanks
Vish


> 
> From: "Kai Ruottu" <karuottu@mbnet.fi>
> Date: 2004/02/04 Wed PM 03:26:18 EST
> To: vishu27@cox.net
> Subject: Re: building gcc toolchain for xscale-coff
> 
> On 2 Feb 2004 at 14:21, vishu27@cox.net wrote:
> 
> > I have tried building a gcc toolchain for xscale-coff using the directions
> > from the bgatliff script. But i get the errors as I have stated in 
> > 
> > http://sources.redhat.com/ml/crossgcc/2003-10/msg00219.html
> > 
> > I then tried the method that Kai Ruottu sent in the message
> > 
> > http://sources.redhat.com/ml/crossgcc/2003-10/msg00254.html
> > 
> > But i get the same results.
> 
>  Working offline these URLs has no meanings, but seeing my archives
> lets me guess your problem to be the following :
> 
> >> On executing the make command, I get the following error
> >>
> >> In file included from ../../../../gcc-3.1/libstdc++-
> v3/libsupc++/eh_alloc.cc:34:
> >> /nfs/iadusr02/vsankara/xscale-gnu/build-gcc/xscale-elf/libstdc++-
> v3/include/cstdlib:86: `
> >>   div_t' not declared
> >> /nfs/iadusr02/vsankara/xscale-gnu/build-gcc/xscale-elf/libstdc++-
> v3/include/cstdlib:87: `
> >>   ldiv_t' not declared
> >> /nfs/iadusr02/vsankara/xscale-gnu/build-gcc/xscale-elf/libstdc++-
> v3/include/cstdlib:97: `
> >>   div' not declared
> 
> which hints you having a stub 'stdlib.h' header instead of the right
> 'stdlib.h' one coming with newlib. A search like:
> 
> D:\usr\local\xscale-elf\include>grep ldiv_t *.h
> stdlib.h:} ldiv_t;
> stdlib.h:ldiv_t _EXFUN(ldiv,(long __numer, long __denom));
> 
> tells these structs, protos etc. existing  So did you really make the
> required symlinks from 'include' to 'sys-include' or copy the told
> headers to be seen there during the GCC build?  If the GCC build
> cannot see these headers existing, it replaces them with its own
> stubs, which don't work as well as the real stuff... So the headers:
> 
>   limits.h, stdio.h, stdlib.h, string.h, time.h, unistd.h
> 
> MUST be seen in the '$prefix/$target/sys-include' during the GCC
> build, this is the list for gcc-3.4, a less amount of files, without
> the 'string.h' and 'time.h', is enough with gcc-3.3.x and earlier...
> 
>  This "sys-include bug" seems to have become a "feature" and
> there seems to be no intention to fix it ever...  Putting all the
> 'generic' newlib headers into the 'sys-include' and removing
> them after the GCC and newlib builds could serve as a
> workaround, but the same problem comes when updating GCC,
> those headers must be seen there.  Every newlib-update then
> puts its newer headers into the 'include' and if the 'sys-include'
> has only copies from the older headers, these too must be updated
> after the newlib install. If the stuff in 'sys-include' is only 
> symlinks, they will stay in sync with the headers in 'include'...
> 
>  Anyway a mess which could easily be avoided, but why there
> is no wish to to it after it causing problems for years, is unclear.
> Unless the case then is "this is the law... The feature was stated
> by the law and nobody can change the law" :-)  If quoting the
> 'gcc/ChangeLog.0' :
> 
> Tue May 19 22:31:20 1998  Jeffrey A Law  (law@cygnus.com)
> 
> 	* Makefile.in (deduced.h): Only run scan-types if 
> $(SYSTEM_HEADER_DIR)
> 	exists.
> 	(stmp-fixproto): Simlarly for running fixproto.
> 	* cross-make (SYSTEM_HEADER_DIR): Now $(tooldir)/sys-include.
> 
> this seems to be the 'original bug' causing the whole mess...
> 
>  I mean that too important faces could be lost if this "feature"
> would ever be fixed... Telling that the head of the GCC development
> team could make any mistakes would be just as bad as claiming that
> Richard M. Stallman or Linus Torvalds could make any mistakes...
> (I remember Jeff Law now being the main boss...)
> 
> > I would appreciate it if some one could give the exact steps
> > to build the xscale-coff toolchain so that it works.
> 
>  Doing the required symlinks should make the job easy as a pie...
> 
> 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