Re: Re: building gcc toolchain for xscale-coff

["Kai Ruottu" <karuottu at mbnet dot fi>]

On 4 Feb 2004 at 17:14, vishu27@cox.net wrote:

> 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

 Nothing here tells about your used GCC version.... All the previous
tells this GCC version being seriously broken.  I have built the GCC
versions 3.2.3, 3.3.1 and 3.3.2 for xscale-coff on Linux and there
was nothing like this...

  Or your '/nfs' means that the build directory is NFS-mounted and
there is some problem related to this arrangement, ie. transfer 
errors in the net...  Copying a 30 Mbyte or bigger file from a Win98
PC to a WinNT4.0 PC seemed to fail always recently here, faulty
netcards or something but gradually I have learned to not trust any
network connections working always ok...

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

 The " make[7]: *** [strstream.lo] Error 1" tells the error coming 
when trying to compile 'strstream.cc' or something and the 'str'
in it hints to the 'string.h'...  Are you trying to use the gcc-3.4
snapshots, an experimental or a prerelease version?  There
symlinking the 'string.h' and 'time.h' too is obligatory. If so and
even in any case, please check your buildir
     /nfs/iadusr02/vsankara/xscale-gnu/build-gcc/gcc/include
for any of those
    limits.h, stdio.h, stdlib.h, string.h, time.h, unistd.h
headers, others than the 'limits.h' shouldn't be there and the
'limits.h' must be the GCC's own which #include's the
'syslimits.h', which then #include_next's the newlib's own
'limits.h'.  If there are any of these other headers, please
check their 'fixes' for sanity by making diffs to the originals.
In the gcc-3.3.2 case none of these other headers became
'fixed' here.  Generally the 'fixing' has been broken now and
then, especially in gcc-3.0.x and maybe still in gcc-3.1.x,
giving pure bullshit in the 'fixed' headers... So checking what
on earth the header-fixing did with the "already compatible
with GCC" newlib headers is a must with with gcc-3.0.x and
gcc-3.1.x...

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