|
From: | Florian Weimer |
Subject: | 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 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |