On (01/11/10 12:36), Tom Rini wrote: > Khem Raj wrote: > >Hi > > > >There are so many versions of toolchain components gcc/binutils/glibc that > >we have in metadata. I would like to reduce the number and keep supporting > >the ones we really use. Right now we have recipes for > > > >binutils = 2.14.90.0.6,2.14.90.0.7, 2.15.94.0.1, 2.16, 2.16.1, 2.16.91.0.6, > >2.16.91.0.7, 2.17, 2.17.50.1, 2.17.50.0.5, 2.17.50.0.8, 2.17.50.0.12, 2.18, > >2.18.50.0.7, 2.18.atmel.1.0.1, 2.19, 2.19.1, 2.19.51, 2.19.51.0.3, 2.20, > >2.20.1, cvs > > > >gcc = 3.3.3, 3.3.4, 3.4.3, 3.4.4, 3.4.6, 4.0.0, 4.0.2, 4.1.0, 4.1.1, 4.1.2, > >4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.4.1, 4.4.2, > >4.4.4, 4.5, csl-arm-2007q3, csl-arm-2008q1, csl-arm-2008q3 > > > >glibc = 2.2.5, 2.3.2, 2.3.3, 2.3.5+cvs20050627, 2.5, 2.6.1, 2.9, 2.10.1, > >cvs > > > >uclibc = 0.9.28, 0.9.29, 0.9.30, 0.9.30.1, 0.9.30.2, 0.9.30.3, 0.9.31, git > > > > > >eglibc = 2.9, 2.10, 2.11, 2.12, svn > > For flexibility in out of tree projects, I'd like to see us keep at > least for binutils 2.18 and newer (official releases) and one each > of the H.J. Lu releases (.5x.y.z) for folks that need that. > Similarly for gcc, 4.2.4, 4.3.4, 4.4.4 and one of the csl's. For > glibc, 2.9 and newer? For uclibc maybe we can drop 0.9.30.[12] if > they aren't pinned. > > But I fear this won't help your concern as much since often fixing > up for say gcc 4.2.4 fixes it up for 4.2.1 and 4.2.2 and 4.2.3, and > so forth.
Well my intention is to keep the versions that we can build and maintain. I plan to rework the .inc file mess once we have limited the versions to support > > -- > Tom Rini > Mentor Graphics Corporation > > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
