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: crosstool-0.40 released: gcc-4.1 rc1 support


My 2 cents:

I'm a bit of a revsionist, but I'd like to see the maintinanece of the
matrix of at least the official past releases of the open source
components involved in building a cross compiler.  Why throw the
knowledge away?  Because it is hard to maintain in the face of new
development.  Why keep it?  As Dan and others more or less said, some
instituions are reluctant to abandoning what was known to work.  They
have products out there, and can't afford to throw another variable into
the mix at release time...

Crosstools is an excelent repository of what it takes to get these
diverse open source software components work together.  I wish I had
more knowlege and time to help.  I don't.

I've seen reference to Karim Yaghmour's book "Building Embedded Linux
Systems" here.  A decent book, and it has the essentials in building a
tool chain, just not all the nitty gritty, patches, etc.. 

Myself, personally, I'd pick the oldest versions, known to work.  I just
want to get on to the application.

Like I said, 2 cents.

Earl



> -----Original Message-----
> From: crossgcc-owner@sourceware.org 
> [mailto:crossgcc-owner@sourceware.org] On Behalf Of Khem Raj
> Sent: Tuesday, February 21, 2006 2:52 PM
> To: Dan Kegel
> Cc: Allen Curtis; Robert Schwebel; crossgcc@sourceware.org
> Subject: Re: crosstool-0.40 released: gcc-4.1 rc1 support
> 
> Dan Kegel said the following on 02/21/2006 01:41 PM:
> > On 2/21/06, Allen Curtis <acurtis@onz.com> wrote:
> >   
> >> I work in embedded systems. My clients have new and old 
> Linux based 
> >> projects. In many cases the client will choose to stick with older 
> >> toolchains and libraries because they are a known 
> quantity. It would 
> >> be detrimental to me and my clients if this utility did 
> not support 
> >> older versions of GCC and libc.
> >>     
> >
> > What do you think about removing support for, say, 
> gcc-3.3.4 when we 
> > add support for gcc-3.3.6?  i.e. keeping only the two most recent 
> > micro releases of each main track of gcc?
> >   
> I like this idea. It will work for gcc one (latest) release 
> from  3.3.x, 3.4.x, 4.0.x and 4.1.x generally minor release 
> which increments in third digit are really minor and should 
> not have major features that can break compatibility
> > ------
> > Want more information?  See the CrossGCC FAQ, 
> > http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to 
> > crossgcc-unsubscribe@sourceware.org
> >
> >   
> 
> 
> ------
> Want more information?  See the CrossGCC FAQ, 
> http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a 
> note to crossgcc-unsubscribe@sourceware.org
> 
> 

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.org


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