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.

--
Tom Rini
Mentor Graphics Corporation

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Reply via email to