|
| From: | Paul Eggert |
| Subject: | bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90 |
| Date: | Mon, 20 Jun 2016 12:04:50 +0200 |
| User-agent: | Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 |
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.
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).
Perhaps poisoning __malloc_initialize_hook helps for some theoretical applications, but for Emacs I don't see how it is a win.
| [Prev in Thread] | Current Thread | [Next in Thread] |