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