This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.24 -- Release blockers
On Thu, 2016-07-14 at 10:41 +0200, Andreas Schwab wrote:
> Torvald Riegel <triegel@redhat.com> writes:
>
> > On Thu, 2016-07-14 at 10:32 +0200, Andreas Schwab wrote:
> >> Torvald Riegel <triegel@redhat.com> writes:
> >>
> >> > On Thu, 2016-07-14 at 10:23 +0200, Andreas Schwab wrote:
> >> >> Florian Weimer <fweimer@redhat.com> writes:
> >> >>
> >> >> > I don't know if there is anything on the glibc side that we can reasonably
> >> >> > do about this matter. I don't want to back out the removal of
> >> >> > __malloc_initialize_hook from <malloc.h> (which triggers the switch to the
> >> >> > internal malloc).
> >> >>
> >> >> Apparently it's not ready for the world yet.
> >> >
> >> > It rather seems to be the case that a part of the world (ie, emacs)
> >> > still hasn't managed to not use internals of glibc, or fixed its own
> >> > work-arounds.
> >>
> >> Yes, but that needs to be resolved before the release.
> >
> > IIRC, Florian started this several months ago, so it seems emacs should
> > have had enough time to catch up by now. Also, bugs in their own malloc
> > replacement hardly seem like something we'd be responsible for.
>
> We are responsible for removing a supported interface.
AFAIU, the remaining emacs failure is a bug in *emacs' own* malloc
implementation. While it seems that what we do triggers this problem,
it's pretty clearly a bug they should have fixed and will have to fix
anyway.
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?