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 #24 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 10:48:19 +0200

On 06/19/2016 05:02 AM, Paul Eggert wrote:
> If I understand things correctly, the Emacs 'configure' script
> discovered that the test glibc version did not declare and define a
> symbol __malloc_initialize_hook, and so Emacs supplied its own
> implementation of malloc, complete with __malloc_initialize_hook. Since
> __malloc_initialize_hook was poisoned, this didn't work.

Yes, that's right.  I didn't account for the possibility that Emacs 
would use symbols in the implementation namespace for implementing its 
own malloc.

> I suppose Emacs could work around the problem by using
> __malloc_initialize_hook when linked against an old glibc, and by using
> a new symbol emacs_malloc_initialize_hook when linked against its
> substitute implementation. Although this would insulate distant-future
> versions of Emacs against the poisoning, it wouldn't work for Emacs 25
> (the next Emacs version) and earlier; these systems would be unbuildable
> with a glibc that poisons __malloc_initialize_hook. So as a practical
> matter, aren't we better off having glibc simply not declare
> __malloc_initialize_hook?

You mean, not declare it in <malloc.h>?  I already posted a patch for that:

  <https://sourceware.org/ml/libc-alpha/2016-06/msg00500.html>

I'm more worried about the other __ variables in the Emacs malloc. 
Their in Emacs definition does not even match the one in glibc.  The 
difference is probably harmless, but it is fairly close to be being broken.

Thanks,
Florian

Previous Next

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