GNU bug report logs - #23760
25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90

Previous Next

Full log

Message #36 received at 23760 <at> debbugs.gnu.org (full text, mbox):

From: Florian Weimer <fweimer <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Jan Synáček
 <jsynacek <at> redhat.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 23760 <at> debbugs.gnu.org
Subject: Re: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Mon, 20 Jun 2016 12:15:40 +0200

On 06/20/2016 12:04 PM, Paul Eggert wrote:
> On 06/20/2016 11:21 AM, Florian Weimer wrote:
>>
>> The usual mechanism for deprecation and removal of an API does not
>> work if the symbol is interposed because it will be unversioned, and
>> unversioned symbols preempt versioned symbols.  As a result, even if
>> the symbol is a compat symbol, you can produce new binaries which use
>> the removed API.
>>
>
> True, but in this particular case Emacs is replacing malloc as well as
> __malloc_initialize_hook etc., so I don't see a problem. Although new
> Emacs binaries will still use the removed API, they will also support
> the removed API.

You need just one linked DSOs which somehow manages to call a function 
in the glibc malloc implementation, and interesting things will happen.

> What *could* be a problem is if the new glibc malloc API supplies
> symbols that Emacs does not supply, and if other parts of the new glibc
> use these symbols. But I don't see this happening either (and if it did
> happen, poisoning __malloc_initialize_hook wouldn't fix it).

We already have this problem with malloc_usable_size, and perhaps some 
of the aligned allocation functions.

This reminds me of this glibc bug, which I've put on my list to fix:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=17730>

I think after that, at least glibc will be interposition-clean.

> Perhaps poisoning __malloc_initialize_hook helps for some theoretical
> applications, but for Emacs I don't see how it is a win.

I'm worried that Emacs developers decide to ignore the API removal and 
keep using glibc malloc and the malloc_set_state function it provides. 
If we can turn the latter into a compatibility symbol during this 
development cycle, that would go a long way towards addressing my concern.

Florian

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.