Xemacs and dmalloc both build with the currently released version of glibc (2.2.4-19.3), but fail with glibc-2.2.5-27. Dmalloc grows to consume all memory and is killed, xemacs gets internal failures of it.
Can you please mention details about xemacs failures (ie. what should I run to reproduce it)?
Just grab the xemacs package in the 7.3-beta and do a "rpm --rebuild".
In the xemacs case, what leads you to believe it is an glibc bug and not something else? xemacs crashes for me both if I run: ./xemacs -batch -vanilla -f list-load-path-shadows l/ld-linux.so.2 --library-path l/ ./xemacs -batch -vanilla -f list-load-path-shadows /lib/ld-linux.so.2 --library-path /lib/ ./xemacs -batch -vanilla -f list-load-path-shadows (l/ is subdirectory populated with glibc-2.2.4-19.3 libraries).
I installed the public beta, and it failed during build. I downgraded glibc to the release version, and it built fine. No other changes made.
Trond, could you work on debugging this too? It is very likely this is an xemacs bug (I already found one thinko in unexelf.c), although it is triggered by glibc change. So far I know that: ./temacs -nd -batch -l /usr/src/redhat/BUILD/xemacs-21.4.6/src/../lisp/loadup.el dump when run with old glibc creates a working xemacs binary (which works with whatever glibc is tried), while running the above command against new glibc creates somewhat smaller xemacs binary which crashes (it doesn't matter at all what glibc was temacs binary compiled against). The bug I found so far is that unexelf.c doesn't clear NEW_SECTION_H(0) record, so it can contain total garbage.
I've backed out new malloc from Hampton glibc, though this will need to be debugged for Milan. The huge size difference between xemacs built with glibc-2.2.5-27 (4672454) and glibc-2.2.5-29 (5042174) shows the new malloc being superior to the old one wrt. fragmentation, just xemacs is somewhere relying on something it should not :(. IMHO this unexelf thingie is broken by design.
Will need to be solved for Milan...