This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Glibc stable release process (Glibc 2.26.1)
- From: Arjan van de Ven <arjan at linux dot intel dot com>
- To: Romain Naour <romain dot naour at gmail dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: Joseph Myers <joseph at codesourcery dot com>, "Gabriel F. T. Gomes" <gabriel at inconstante dot eti dot br>, Siddhesh Poyarekar <siddhesh at sourceware dot org>, "Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>
- Date: Fri, 29 Sep 2017 17:38:53 -0700
- Subject: Re: Glibc stable release process (Glibc 2.26.1)
- Authentication-results: sourceware.org; auth=none
- References: <60f78cac-9cf4-51b1-9ade-21cd09783d96@gmail.com>
On 9/29/2017 1:17 PM, Romain Naour wrote:
Hello All,
As suggested by Siddhesh Poyarekar in BZ-22146 [0], I'd like to continue the
discussion about tagging a 2.26.1 release.
Glibc 2.26 introduced some regressions (notably BZ-21930 and BZ-22146) on major
architectures (x86 and x86_64) that are already fixed in the stable branch.
Without them, we can't compile C++ any code using mathematical functions (ex:
std::fpclassify() when libstdc++ is compiled with -Os).
Siddhesh Poyarekar said that is no plan for a new release since most
distributions prefer to backport patches. But for downstream users like build
tools (Buildroot, crosstool-ng, Yocto...) that use the release archives, it
means that a lot of patches need to be backported (42 at the time of writing).
as someone who does glibc for a distro... I strongly prefer tarbal releases.
There's a lot less ambiguity in terms of what is running, and distros generally
are set up to take tarbals anyway....
taking a patch or two is fine, but doing this over and over again makes it less
obvious what exact stack is running etc.