[Buildroot] [PATCH] glibc: add 2.19 as a supported version

[Buildroot] [PATCH] glibc: add 2.19 as a supported version

[Thomas Petazzoni]

glibc 2.19 has been released recently
(https://sourceware.org/ml/libc-alpha/2014-02/msg00224.html). This
commit allows to build a toolchain with this new version. In order to
allow this, we add a version selection that did not exist for
glibc. We default to 2.18, which was the only supported version until
now, and add an option for 2.19.

For microblaze, which uses a specific glibc version, the version
selection choice is not displayed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/glibc/Config.in                 | 21 +++++++++++++++++++++
 package/glibc/glibc.mk                  |  2 +-
 toolchain/toolchain-buildroot/Config.in |  2 +-
 3 files changed, 23 insertions(+), 2 deletions(-)
 create mode 100644 package/glibc/Config.in

diff --git a/package/glibc/Config.in b/package/glibc/Config.in
new file mode 100644
index 0000000..a92b5ea
--- /dev/null
+++ b/package/glibc/Config.in
@@ -0,0 +1,21 @@
+if BR2_TOOLCHAIN_BUILDROOT_GLIBC
+
+choice
+	prompt "glibc version"
+	default BR2_GLIBC_VERSION_2_18
+	# Architectures supported in mainline glibc
+	depends on BR2_arm    || BR2_armeb    || BR2_aarch64 || \
+		   BR2_i386   || BR2_mips     || BR2_mipsel  || \
+		   BR2_mips64 || BR2_mips64el || BR2_powerpc || \
+		   BR2_sh     || BR2_sh64     || BR2_sparc   || \
+		   BR2_x86_64
+
+config BR2_GLIBC_VERSION_2_18
+       bool "2.18"
+
+config BR2_GLIBC_VERSION_2_19
+       bool "2.19"
+
+endchoice
+
+endif
diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
index 96de02a..89eaaf6 100644
--- a/package/glibc/glibc.mk
+++ b/package/glibc/glibc.mk
@@ -21,7 +21,7 @@ GLIBC_SITE = http://downloads.yoctoproject.org/releases/eglibc/
 GLIBC_SOURCE = eglibc-$(GLIBC_VERSION).tar.bz2
 GLIBC_SRC_SUBDIR = libc
 else
-GLIBC_VERSION = 2.18
+GLIBC_VERSION = $(if $(BR2_GLIBC_VERSION_2_19),2.19,2.18)
 GLIBC_SITE = $(BR2_GNU_MIRROR)/libc
 GLIBC_SOURCE = glibc-$(GLIBC_VERSION).tar.xz
 GLIBC_SRC_SUBDIR = .
diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
index cd88889..eb5ee46 100644
--- a/toolchain/toolchain-buildroot/Config.in
+++ b/toolchain/toolchain-buildroot/Config.in
@@ -70,7 +70,7 @@ config BR2_TOOLCHAIN_BUILDROOT_LIBC
 	default "glibc"  if BR2_TOOLCHAIN_BUILDROOT_GLIBC
 
 source "package/uclibc/Config.in"
-
+source "package/glibc/Config.in"
 source "package/binutils/Config.in.host"
 source "package/gcc/Config.in.host"
 source "package/elf2flt/Config.in.host"
-- 
1.8.3.2

[Buildroot] [PATCH] glibc: add 2.19 as a supported version

[Arnout Vandecappelle]

On 02/10/14 18:43, Thomas Petazzoni wrote:
> glibc 2.19 has been released recently
> (https://sourceware.org/ml/libc-alpha/2014-02/msg00224.html). This
> commit allows to build a toolchain with this new version. In order to
> allow this, we add a version selection that did not exist for
> glibc. We default to 2.18, which was the only supported version until
> now, and add an option for 2.19.

 How useful is it to offer a choice for the libc version?

 For uClibc it makes a tiny bit of sense because you may have custom
patches or a custom config, which you don't want to port when going to a
new buildroot version. But I don't think that's a very good reason to
begin with.

 For glibc, however, I really don't see a reason to keep multiple versions.


 Regards,
 Arnout

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

[Buildroot] [PATCH] glibc: add 2.19 as a supported version

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Mon, 10 Feb 2014 21:29:59 +0100, Arnout Vandecappelle wrote:

>  How useful is it to offer a choice for the libc version?
> 
>  For uClibc it makes a tiny bit of sense because you may have custom
> patches or a custom config, which you don't want to port when going to a
> new buildroot version. But I don't think that's a very good reason to
> begin with.
> 
>  For glibc, however, I really don't see a reason to keep multiple versions.

My plan was to offer no more than two versions: N-1 and N, so that we
can add N, and give it some testing before having all users move
immediately from N-1 to N. This is pretty much what we do with gcc,
binutils and gdb as well. I believe the toolchain components are quite
critical, that's why we're a bit more conservative with these than with
the other components.

Do we have a reason to keep multiple versions for binutils, gcc and
gdb, but not for glibc?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] glibc: add 2.19 as a supported version

[Arnout Vandecappelle]

On 02/10/14 23:41, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> On Mon, 10 Feb 2014 21:29:59 +0100, Arnout Vandecappelle wrote:
> 
>>  How useful is it to offer a choice for the libc version?
>>
>>  For uClibc it makes a tiny bit of sense because you may have custom
>> patches or a custom config, which you don't want to port when going to a
>> new buildroot version. But I don't think that's a very good reason to
>> begin with.
>>
>>  For glibc, however, I really don't see a reason to keep multiple versions.
> 
> My plan was to offer no more than two versions: N-1 and N, so that we
> can add N, and give it some testing before having all users move

 I don't think there will be a lot of testing happening there...

> immediately from N-1 to N. This is pretty much what we do with gcc,
> binutils and gdb as well. I believe the toolchain components are quite
> critical, that's why we're a bit more conservative with these than with
> the other components.
> 
> Do we have a reason to keep multiple versions for binutils, gcc and
> gdb, but not for glibc?

 No, I don't think we have a reason to keep multiple versions for
binutils, gdb, and also busybox BTW.

 For gcc it's a bit more appropriate. I have seen (proprietary) packages
that fail to build with a different gcc version - usually because of
-Werror and different warnings in -Wall.


 Having multiple versions also means that you need:

- multiple autobuilder instances (preferably for all architectures) to
cover both versions;

- legacy stuff for the old versions;

- a deprecation path for the old versions.

 So it's really quite a bit of overhead for IMHO limited advantage.

 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

[Buildroot] [PATCH] glibc: add 2.19 as a supported version

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >>> For glibc, however, I really don't see a reason to keep multiple versions.
 >> 
 >> My plan was to offer no more than two versions: N-1 and N, so that we
 >> can add N, and give it some testing before having all users move

 >  I don't think there will be a lot of testing happening there...

Why not?

 >  No, I don't think we have a reason to keep multiple versions for
 > binutils, gdb, and also busybox BTW.

I'm certainly open to limit the number of options, but completely
removing them right away is imho too much.

 >  For gcc it's a bit more appropriate. I have seen (proprietary) packages
 > that fail to build with a different gcc version - usually because of
 > -Werror and different warnings in -Wall.

Another example is older Linux kernels (E.G. for projects stuck with a
non-mainline BSP).

-- 
Bye, Peter Korsgaard

[Buildroot] Supporting multiple versions of toolchain components?

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

(Renaming the thread topic to attract readers!)

On Tue, 11 Feb 2014 09:05:36 +0100, Arnout Vandecappelle wrote:

> > My plan was to offer no more than two versions: N-1 and N, so that we
> > can add N, and give it some testing before having all users move
> 
>  I don't think there will be a lot of testing happening there...

That is indeed true, but I'm pretty sure some advanced users test the
latest versions of the various components.

> > Do we have a reason to keep multiple versions for binutils, gcc and
> > gdb, but not for glibc?
> 
>  No, I don't think we have a reason to keep multiple versions for
> binutils, gdb, and also busybox BTW.

Having multiple versions of busybox seems clearly useless to me. For
the other ones, my opinion is more balanced.

But switching to only one version for binutils, gcc and gdb would
certainly be a change from the Buildroot tradition. Not saying whether
this is good or bad, but it's clearly moving away from what we have
been doing for a long time.

>  For gcc it's a bit more appropriate. I have seen (proprietary) packages
> that fail to build with a different gcc version - usually because of
> -Werror and different warnings in -Wall.

Or also because of things like:
http://git.buildroot.net/buildroot/commit/package/gcc?id=c443c2be1768ebbdcb76c55d0a08fd7c983488c8.
And because very often, the .0 of a gcc release is broken on some
architectures.

>  Having multiple versions also means that you need:
> 
> - multiple autobuilder instances (preferably for all architectures) to
> cover both versions;

That's not true. A single autobuilder instance can work on as many
toolchain configurations as you want. My autobuilder instance chooses
randomly between the configurations at
http://autobuild.buildroot.org/toolchains/configs/free-electrons/.

> - legacy stuff for the old versions;

Right.

> - a deprecation path for the old versions.

I don't really see why. For all packages, we're just bumping. For
gcc/binutils/gdb/uClibc, we're keeping older versions around a little
bit longer. Provided with have the Config.in.legacy safety net, I don't
see why we should go through a deprecation path for those old versions,
while we aggressively bump all other packages without any deprecation.

>  So it's really quite a bit of overhead for IMHO limited advantage.

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.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Supporting multiple versions of toolchain components?

[Arnout Vandecappelle]

On 11/02/14 09:32, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> (Renaming the thread topic to attract readers!)
> 
> On Tue, 11 Feb 2014 09:05:36 +0100, Arnout Vandecappelle wrote:
> 
>>> My plan was to offer no more than two versions: N-1 and N, so that we
>>> can add N, and give it some testing before having all users move
>>
>>  I don't think there will be a lot of testing happening there...
> 
> 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?

> 
>>> Do we have a reason to keep multiple versions for binutils, gcc and
>>> gdb, but not for glibc?
>>
>>  No, I don't think we have a reason to keep multiple versions for
>> binutils, gdb, and also busybox BTW.
> 
> Having multiple versions of busybox seems clearly useless to me. For
> the other ones, my opinion is more balanced.

 So you do see a reason to use an older binutils or gdb?


> But switching to only one version for binutils, gcc and gdb would
> certainly be a change from the Buildroot tradition. Not saying whether
> this is good or bad, but it's clearly moving away from what we have
> been doing for a long time.
> 
>>  For gcc it's a bit more appropriate. I have seen (proprietary) packages
>> that fail to build with a different gcc version - usually because of
>> -Werror and different warnings in -Wall.
> 
> Or also because of things like:
> http://git.buildroot.net/buildroot/commit/package/gcc?id=c443c2be1768ebbdcb76c55d0a08fd7c983488c8.
> And because very often, the .0 of a gcc release is broken on some
> architectures.

 ACK.

> 
>>  Having multiple versions also means that you need:
>>
>> - multiple autobuilder instances (preferably for all architectures) to
>> cover both versions;
> 
> That's not true. A single autobuilder instance can work on as many
> toolchain configurations as you want. My autobuilder instance chooses
> randomly between the configurations at
> http://autobuild.buildroot.org/toolchains/configs/free-electrons/.

 What I mean is: you need to multiply the number of configurations, and
therefore to get the same coverage you need to multiply the number of
autobuilder instances.

 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.

> 
>> - legacy stuff for the old versions;
> 
> Right.
> 
>> - a deprecation path for the old versions.
> 
> I don't really see why. For all packages, we're just bumping. For
> gcc/binutils/gdb/uClibc, we're keeping older versions around a little
> bit longer. Provided with have the Config.in.legacy safety net, I don't
> see why we should go through a deprecation path for those old versions,
> while we aggressively bump all other packages without any deprecation.

 OK.

 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.


> 
>>  So it's really quite a bit of overhead for IMHO limited advantage.
> 
> 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.

 Regards,
 Arnout

> 
> Thanks,
> 
> 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

[Buildroot] Supporting multiple versions of toolchain components?

[Thomas Petazzoni]

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.

> >>  No, I don't think we have a reason to keep multiple versions for
> >> binutils, gdb, and also busybox BTW.
> > 
> > Having multiple versions of busybox seems clearly useless to me. For
> > the other ones, my opinion is more balanced.
> 
>  So you do see a reason to use an older binutils or gdb?

I believe it's just extra caution. Toolchain components tend to be more
delicate than other packages. That's why we almost never default to the
latest version of gcc, binutils and gdb in Buildroot.

> >>  Having multiple versions also means that you need:
> >>
> >> - multiple autobuilder instances (preferably for all architectures) to
> >> cover both versions;
> > 
> > That's not true. A single autobuilder instance can work on as many
> > toolchain configurations as you want. My autobuilder instance chooses
> > randomly between the configurations at
> > http://autobuild.buildroot.org/toolchains/configs/free-electrons/.
> 
>  What I mean is: you need to multiply the number of configurations, and
> therefore to get the same coverage you need to multiply the number of
> autobuilder instances.
> 
>  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.

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

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Supporting multiple versions of toolchain components?

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

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

Sounds good to me. Let's also do the same for kernel headers. We still
need to keep the arch specific versions though.

Will you send patches or should I do it myself?

-- 
Bye, Peter Korsgaard

[Buildroot] Supporting multiple versions of toolchain components?

[Arnout Vandecappelle]

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

[Buildroot] Supporting multiple versions of toolchain components?

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Wed, 12 Feb 2014 18:37:20 +0100, Arnout Vandecappelle wrote:

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

Probably not, indeed. But by introducing 2.19 as an option, the hope is
that a few users will actually try this out.

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

Yes, I agree.

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

Perfect. I'll try to implement this policy, then.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] glibc: add 2.19 as a supported version

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > glibc 2.19 has been released recently
 > (https://sourceware.org/ml/libc-alpha/2014-02/msg00224.html). This
 > commit allows to build a toolchain with this new version. In order to
 > allow this, we add a version selection that did not exist for
 > glibc. We default to 2.18, which was the only supported version until
 > now, and add an option for 2.19.

 > For microblaze, which uses a specific glibc version, the version
 > selection choice is not displayed.

 > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Committed to next, thanks.

-- 
Bye, Peter Korsgaard