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

Previous Next

Package: emacs;

Reported by: jsynacek <at> redhat.com (Jan Synáček)

Date: Mon, 13 Jun 2016 10:49:01 UTC

Severity: normal

Tags: patch

Merged with 24033, 24204

Found in version 25.0.95

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jan Synáček <jsynacek <at> redhat.com>
Cc: Florian Weimer <fweimer <at> redhat.com>, Glenn Morris <rgm <at> gnu.org>, 23760 <at> debbugs.gnu.org
Subject: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Sun, 19 Jun 2016 05:02:17 +0200
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.

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? That should work with older Emacs versions, 
which is a win. I don't see a significant practical advantage to 
poisoning the symbol.




This bug report was last modified 8 years and 347 days ago.

Previous Next


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