[RFC] Toolchain recipes, versions, removal and consolidation

[RFC] Toolchain recipes, versions, removal and consolidation

[Khem Raj]

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

They all use common files. So whenever there is a bugfix needed its a very
hard job to first create a common fix that works across all versions
secondly verify if it works and I am sure 80% of recipe versions mentioned
here dont even build

So I am going to propose to remove most of them which dont build and
request the distro and machine maintainers to please update the list of
toolchain components to keep.

Please voice which versions should we really really keep. This should be a
set which is buildable and functional.

If I dont hear on this in coming weeks then I have a plan in my mind on
which versions to keep

Thanks

-Khem

Re: [RFC] Toolchain recipes, versions, removal and consolidation

[Graham Gower]

On 30 October 2010 05:47, Khem Raj <raj.khem@gmail.com> 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
>
> They all use common files. So whenever there is a bugfix needed its a very
> hard job to first create a common fix that works across all versions
> secondly verify if it works and I am sure 80% of recipe versions mentioned
> here dont even build
>
> So I am going to propose to remove most of them which dont build and
> request the distro and machine maintainers to please update the list of
> toolchain components to keep.
>
> Please voice which versions should we really really keep. This should be a
> set which is buildable and functional.
>
> If I dont hear on this in coming weeks then I have a plan in my mind on
> which versions to keep
>
> Thanks
>
> -Khem
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


I welcome removal of obsolete recipes here. The barrier for others to
create patches will be reduced dramatically.

One further thing: glibc is obsolete for embedded systems, long live eglibc.

-Graham

Re: [RFC] Toolchain recipes, versions, removal and consolidation

[Roman I Khimov]

[-- Attachment #1: Type: Text/Plain, Size: 1496 bytes --]

В сообщении от Пятница 29 октября 2010 23:17:18 автор Khem Raj написал:
> 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

On 2.20.1 here, probably leaving 2.18+ should be fine, although quick grep at 
conf/ shows almost all versions pinned in some way.

> 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

Using 4.4.4, so technically not care about anything other than 4.4.x and 
4.5.x. But I think it's definitely time to kill 3.x. I'd opt for leaving 4.2+ 
and one patchlevel version per minor. Is there any real point in having 4 
4.2.x or 4.3.x versions?

> 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

Not using that, but I'd say that killing it completely maybe is a bit too 
much. 2.9+ or just one latest?

> 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

Using git. Leaving just 0.9.31 and git looks good to me.

> eglibc = 2.9, 2.10, 2.11, 2.12, svn

Not using that, no opinion.

-- 
 http://roman.khimov.ru
mailto: roman@khimov.ru
gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [RFC] Toolchain recipes, versions, removal and consolidation

[Martin Jansa]

On Fri, Oct 29, 2010 at 12:17:18PM -0700, 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
> 
> They all use common files. So whenever there is a bugfix needed its a very
> hard job to first create a common fix that works across all versions
> secondly verify if it works and I am sure 80% of recipe versions mentioned
> here dont even build
> 
> So I am going to propose to remove most of them which dont build and
> request the distro and machine maintainers to please update the list of
> toolchain components to keep.
> 
> Please voice which versions should we really really keep. This should be a
> set which is buildable and functional.

For me sane-toolchain versions + newer are enough. More users of same
versions will provide better testing and in the end better toolchain for
all.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: [RFC] Toolchain recipes, versions, removal and consolidation

[Frans Meulenbroeks]

2010/10/30 Martin Jansa <martin.jansa@gmail.com>:
> On Fri, Oct 29, 2010 at 12:17:18PM -0700, 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
>>
>> They all use common files. So whenever there is a bugfix needed its a very
>> hard job to first create a common fix that works across all versions
>> secondly verify if it works and I am sure 80% of recipe versions mentioned
>> here dont even build
>>
>> So I am going to propose to remove most of them which dont build and
>> request the distro and machine maintainers to please update the list of
>> toolchain components to keep.
>>
>> Please voice which versions should we really really keep. This should be a
>> set which is buildable and functional.
>
> For me sane-toolchain versions + newer are enough. More users of same
> versions will provide better testing and in the end better toolchain for
> all.
>
> Regards,
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>
>

Seems a good plan to me to prune some. Wrt the list:

A nios2 backend *only* exists for gcc 4.1.2. It also needs
binutils_2.17.50.0.12.bb (there is also binutils 2.20.1, but that one
is not fully working yet (and has DP = -1)

For glibc and nios2 I see
glibc/glibc_2.10.1.bb
glibc/glibc_2.5.bb
Not 100% which one is being used. Will peek at it next week.

Frans

Re: [RFC] Toolchain recipes, versions, removal and consolidation

[Tom Rini]

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

Re: [RFC] Toolchain recipes, versions, removal and consolidation

[Khem Raj]

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
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel