[Buildroot] Supporting multiple versions of toolchain components?

[Arnout Vandecappelle <arnout@mind.be>]

On 12/02/14 09:03, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> On Tue, 11 Feb 2014 18:16:08 +0100, Arnout Vandecappelle wrote:
> 
>>> That is indeed true, but I'm pretty sure some advanced users test the
>>> latest versions of the various components.
>>
>>  Do you sometimes do run-time tests of internal glibc toolchain builds?
> 
> Obviously before sending the patch that adds 2.19, I did do a run-time
> test of a minimal ARM glibc+Busybox system in Qemu. The amount of
> testing is minimal, but at least it boots all the way to userspace.

 Yes, but will you do more runtime experiments with glibc 2.19 in the
next 6 months? Probably not, because you simply don't need it.

[snip]
>>  But I didn't realize that the autobuilder test package configurations,
>> not glibc issues, and the packages will fail with either version of
>> glibc. So you're right, this point is moot.
> 
> Your point is not entirely moot. C library headers will be different
> between glibc 2.18 and 2.19, so you could imagine having package build
> failures specific to a given version of glibc. This is typically what
> we have with uClibc (and which was discussed at length during the
> latest meeting), where we have multiple versions of uClibc that don't
> behave the same as they don't offer the same features. However, the
> amount of application-visible changes between glibc 2.18 and 2.19 is
> probably a lot smaller, but maybe not inexistent.

 I think about one third of our autobuilder configurations use an
(e)glibc-based toolchain, with varying versions, and AFAIK we've never
seen a failure on one glibc version but not on others. So I think we can
safely say it is close to non-existent.

> 
>>  So it's just the additional complexity of having the choice, duplicating
>> the patches (none for glibc 2.19), and carrying the legacy. I guess
>> that's not too bad.
> 
> Yes.
> 
>>> Again, I believe what you're proposing is a fairly radical move from
>>> the Buildroot tradition. So we need to get some consensus or decision
>>> here.
>>
>>  Note that I'm not immediately advocating for removing the multiple
>> version support where we have it already. Rather, I propose to not add
>> more multiversion packages.
> 
> I certainly agree with you on this. I would propose to:
> 
>  1/ Remove the multiversion selection on Busybox, because I don't
>     really see why we have this specifically for Busybox.
> 
>  2/ Keep a maximum number of three gcc, binutils, gdb and C library
>     versions. Like: the latest one, the N-1 (default), and the N-2.

 OK!


 Regards,
 Arnout

> 
> Best regards,
> 
> Thomas
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F