Re: glibc 2.24 -- Release blockers

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2016-07-15 at 15:24 +0200, Paul Eggert wrote:
> On 07/15/2016 01:17 PM, Florian Weimer wrote:
> > On 07/15/2016 12:12 PM, Paul Eggert wrote:
> >> On 07/15/2016 10:35 AM, Florian Weimer wrote:
> >>>> I expect such an approach is too much to expect to fold into Emacs 25,
> >>>> which is close to release. We could try something along those lines 
> >>>> for
> >>>> the next major Emacs release, but that won't be for a while.
> >>>
> >>> In this case, I suggest *not* to revert the __malloc_initialize_hook
> >>> removal because if we put it back in, Emacs will not use its internal
> >>> malloc, and we get no additional test coverage compared to we had
> >>> before the removal.
> >>
> >> By "test coverage" do you mean some testing by a buildbot that builds
> >> and runs Emacs with bleeding-edge glibc? If so, we shouldn't need to
> >> remove __malloc_initialize_hook to test this; all that should be needed
> >> is './configure emacs_cv_var_doug_lea_malloc=no', which causes Emacs
> >> 'configure' to pretend that __malloc_initialize_hook does not exist.
> >
> > I meant testing by Emacs developers and users who use pre-release builds.
> >
> > The build barely exercises all the libraries Emacs linked into the 
> > process image.
> >
> >> How about the following more-conservative approach instead?
> >>
> >> 1. Restore __malloc_initialize_hook in glibc.
> >>
> >> 2. Try to get Emacs 25 to work even when configured with './configure
> >> emacs_cv_var_doug_lea_malloc=no'. I'm hoping that something like the
> >> patch I proposed in
> >> <https://sourceware.org/ml/libc-alpha/2016-07/msg00458.html> is enough
> >> to do this, and will be accepted by the Emacs maintainers this close to
> >> a release.
> >>
> >> 3. If (2) is too ambitious for Emacs 25, get it to work with Emacs 26.
> >> This should be quite doable, as essentially the same thing is already
> >> working with Cygwin.
> >>
> >> 4. Once a stable version of Emacs is published with either (2) or (3),
> >> then remove __malloc_initialize_hook from glibc.
> >
> > What worries me is that your proposal still ignores the deprecation of 
> > __malloc_initialize_hook.
> 
> OK, then let's add a new step 3.5, as follows.
> 
> 3.5.  Call the result of step (2) or (3) version N. (Presumably N will 
> be 25 or 26.) In Emacs version N+1, disable use of the system 
> __malloc_initialize_hook. That is, Emacs will no longer set or use the 
> system __malloc_initialize_hook.
> 
> This should address the deprecation concern.
> 
> > We already thought we were at step 4.
> 
> Clearly we were wrong. :-)

Unless I misunderstand your proposal, this wouldn't change anything
regarding Emacs currently using a symbol that has been deprecated.