glibc 2.24 -- Release blockers

[Paul Eggert]

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. :-)