[Buildroot] glibc version choice ?

[Buildroot] glibc version choice ?

[Romain Naour]

Hi All,

All Bootlin toolchains (generated using the Buildroot internal toolchain
backend) has been rebuilt recently [1]. The toolchain-builder project provide
two toolchain versions "stable" and "bleeding-edge" where different versions of
gcc, binutils, linux-headers and gdb are used.

But both toolchain version use the same version of the libc implementation
(glibc, musl and uClibc-ng). I will not talk about musl and uClibc-ng here since
they don't provide stable branches. But the glibc project does [2], even for
very old versions.

It may seem surprising to consider at the moment, a toolchain based on glibc
2.30 or latter "stable".

|  Distro  |  release |  glibc  |
|  Debian  |  Buster  |  2.28   |
|  Ubuntu  |  19.10   |  2.30   |
|  Ubuntu  |  18.04   |  2.27   |
|  Fedora  |  f30     |  2.29   |
|  Fedora  |  f31     |  2.30   |

Glibc (as for musl and uClibc-ng) are critical elements in a Linux system, each
version bump may cause regressions that requires to fix several other projects.
That is also why we use the version N-1 of gcc, binutils and gdb as default
version in Buildroot.

Some example of issues related to glibc:

- The latest version of glibc (2.31) at the time it's released, was not
compiling with existing gcc released version (gcc 8.4 and 9.3 containing a fix
was released after glibc 2.31).

- glibc 2.31 doesn't build with gcc 7.5.0 due to libsanitizer code but the gcc
7.5.0 code will not get maintained anymore.

- openssh needs to be updated to 8.2p1 due to issue with glibc 2.31.

- In the past we had an issue with glibc 2.26 release didn't compile C++ code on
x86 using math function (-Os) [3].

Also recent glibc release increased the requirement on gcc, so we can't compile
glibc 2.30 with gcc < 6.2.

This may be considered as serious issues to consider having a version choice for
glibc package. Some years ago, there was the possibility in Buildroot to choose
among 3 versions, but the choice was removed by [4].

Note: Glibc release two versions per year (Febuary and August), so each version
may not widely used by other Linux distributions.

So what about reintroducing a version choice for glibc,@least a second choice
with the version N-1 ?

[1] https://toolchains.bootlin.com/news.html
[2] https://sourceware.org/pipermail/libc-alpha/2020-March/112367.html
[3] https://lwn.net/Articles/736429/
[4]
https://git.buildroot.net/buildroot/commit/?id=b1ca91c59db667fdd5e59f1a0c8ac11dc0a19816

Best regards,
Romain

[Buildroot] glibc version choice ?

[Yann E. MORIN]

Romain, All,

On 2020-04-05 17:56 +0200, Romain Naour spake thusly:
> So what about reintroducing a version choice for glibc, at least a second choice
> with the version N-1 ?

I am in favour of adding back a version choice for glibc, where we have
a version that points to the a stable release branch, presumably N-1
(but could be N-2 if N-1 is too unstable), which would be the default,
and a version that points to the N branch.

Furthermore, I agree that we should not keep more than two versions.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] glibc version choice ?

[Romain Naour]

Yann, All,

Le 05/04/2020 ? 22:23, Yann E. MORIN a ?crit?:
> Romain, All,
> 
> On 2020-04-05 17:56 +0200, Romain Naour spake thusly:
>> So what about reintroducing a version choice for glibc, at least a second choice
>> with the version N-1 ?
> 
> I am in favour of adding back a version choice for glibc, where we have
> a version that points to the a stable release branch, presumably N-1
> (but could be N-2 if N-1 is too unstable), which would be the default,
> and a version that points to the N branch.
> 
> Furthermore, I agree that we should not keep more than two versions.

Thanks for your reply.

For now, nobody else replied to the question.

I've sent the glibc version bump without re-introducing the version choice [1].
I'm ok to resend a v2 with it :)

[1]
http://patchwork.ozlabs.org/project/buildroot/patch/20200424164851.19897-2-romain.naour at smile.fr/

Best regards,
Romain


> 
> Regards,
> Yann E. MORIN.
>