Glibc stable release process (Glibc 2.26.1)

Arjan van de Ven arjan@linux.intel.com
Sat Sep 30 00:38:00 GMT 2017


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.




More information about the Libc-alpha mailing list