Re: glibc 2.24 -- Release blockers

[Florian Weimer <fweimer at redhat dot com>]

On 07/14/2016 11:09 AM, Torvald Riegel wrote:
> On Thu, 2016-07-14 at 10:59 +0200, Andreas Schwab wrote:
> > Torvald Riegel <triegel@redhat.com> writes:
> >
> > > I can't remember other cases of us not making reasonable changes because
> > > not making them hides bugs in other projects.  Why would emacs be an
> > > exception?
> >
> > It isn't an exception.  It is an unresolved problem.
>
> If there are no cases that are similar, and we generally treat
> user-program bugs differently, it is an exception.  Do you have examples
> in other programs that we treated similarly?

The story around memcpy@@GLIBC_2.14 is similar.  We added an 
optimization to a new symbol version only.  This kept old and buggy 
binaries working, but you could no longer copy new binaries to an older, 
pre-2.14 system and run it there (which usually works, although it is 
technically unsupported).  So in this case, we rated compatibility with 
buggy applications higher than user convenience.

I'm not sure if we have ever done something like that to hide bugs in 
applications which were compiled from source after a glibc update.

Florian