This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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: More crosstool-0.42-glibc-2.4-gcc-4.1.0-nptl


On Wed, 10 May 2006, Khem Raj wrote:

> Robert Schwebel said the following on 05/10/2006 02:43 AM:
> > Steven,
> >
> > On Wed, May 10, 2006 at 10:16:05AM +0100, Steven Newbury wrote:
> >   
> >>> On Wed, May 10, 2006 at 08:42:24AM +0200, Robert Schwebel wrote:
> >>>       
> >>>> I've tried your patch on a debian unstable machine with gcc-4.0.3,
> >>>> 2.16.1cvs20060117-1 and glibc-2.3.6-7 and get this error from the
> >>>> glibc startfiles stage: 
> >>>>         
> >> You probably would be better off with gcc-4.1.0/glibc-2.4.  The EABI
> >> merge caused a lot of flux through 4.0.x and has only stablised in
> >> 4.1.x.
> >>     
> >
> > The problem is that for our PTXdist users (PTXdist uses crosstool
> > internally) normal people, using normal distributions, should be able to
> > build a cross toolchain, which means that we are more or less fixed to
> > what the distributions have these days. And that's what even Debian
> > Unstable currently has. 
> >
> > But if it doesn't work, it doesn't work :-)
> >
> >   
> >>> Update: this seems to happen when you change the -mcpu thing from the
> >>> arm926 to strongarm. Does that mean that for certain ARM sub archs there
> >>> is something missing in binutils? 
> >>>       
> >> It is quite possible.  Are you using an actual StrongARM? 
> >>     
> >
> > No, we mainly use PXA255, PXA270, h720x, i.MX, netX and NetSilicon CPUs.
> > The thing is that, for a generic ARM softfloat toolchain, it should be
> > generic. And setting the cpu to strongarm gave us toolchains which
> > worked on all these architectures. 
> >   
> sometimes gcc/binutils can assume v5t as default architecture when using 
> EABI. So when you select strongarm it may be that somehow
> it does not take care of turning on EABI in all cases. May be no one has 
> tested ARM EABI on older ARM architectures that well.

The one consistent theme I've seen over the issues on this list with EABI 
this past week is that all of us are struggling with armv4t based code.

> > Robert
> >   
> 
> 
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 

--
For unsubscribe information see http://sourceware.org/lists.html#faq


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