From xemacs-m  Tue Feb  4 19:51:56 1997
Received: from herald.cc.purdue.edu (herald.cc.purdue.edu [128.210.11.29])
	by xemacs.org (8.8.5/8.8.5) with SMTP id TAA22308
	for <xemacs-beta@xemacs.org>; Tue, 4 Feb 1997 19:51:54 -0600 (CST)
Received: from ppp-x9-13.ecn.purdue.edu by herald.cc.purdue.edu; Tue, 4 Feb 97 20:51:45 -0500
Received: (from somasekh@localhost) by ppp-x9-13.ecn.purdue.edu (8.8.4/8.6.12) id UAA06579; Tue, 4 Feb 1997 20:50:11 -0500
Date: Tue, 4 Feb 1997 20:50:11 -0500
Message-Id: <199702050150.UAA06579@ppp-x9-13.ecn.purdue.edu>
From: Dinesh Somasekhar <somasekh@ecn.purdue.edu>
To: jaeger@informatik.uni-kl.de
Cc: xemacs-beta@xemacs.org
Subject: Re: GNU libc 2.0 & xemacs-19.15-beta92, more problems & success!
In-Reply-To: <m0vrscS-0001jRC@arthur.pfalz.de>
References: <m0vrscS-0001jRC@arthur.pfalz.de>
Reply-To: somasekh@ecn.purdue.edu
X-URL: http://albrecht.ecn.purdue.edu/~somasekh
X-Organization: Purdue University
X-face:  57,u^#nsk>2N2INb(Afe~^~B}j[t7+B)>u]%DYS:\XA8yL6?[*<0"yBBb@*u/e@K#F6?Fi5
 WB?GMJvJPt$5W0bRNZ{dH%ybQO%$]M)b~_G[!*0"[82&2t[3o{EQB87/0J@AtN6@cz1zM_FD1~{maV
 ;qd6T/s(+&j&QJ"zv5'GQU%10P\R)}aW1xq3(;U<M}8W^~Y:4M9cnj"M+R9_FKM%E[HEyle7['_!|i
 (


Hi,

  I have a similar configuration as yours.  Was just wondering if you
could try compiling with --use-system-malloc.  I tried and got seg
faults.

  I was interested in knowing if it works for you.

--
Dinesh

P.S.  this is not copied to list

"Andreas" == Andreas Jaeger <aj@arthur.pfalz.de> writes:

 > I've got xemacs-19.15-beta92 running in the following
 > configuration: Linux 2.0.28, gcc-2.7.2.1, GNU libc 2.01

 > /usr/glibc/src/xemacs-19.15-betaXX/configure --run-in-place
 > --with-menubars=lucid --with-scrollbars=lucid --with-dialogs=athena

 > Configured for `i486-unknown-linux2.0.28'.

 >   Where should the build process find the source code?
 > /usr/glibc/src/xemacs-19.15-betaXX What installation prefix should
 > install use?  ${srcdir} What operating system and machine
 > description files should XEmacs use?  `s/linux.h' and
 > `m/intel386.h' What compiler should XEmacs be built with?  gcc -g
 > -O Should XEmacs use the GNU version of malloc?  yes Should XEmacs
 > use the relocating allocator for buffers? yes What window system
 > should XEmacs use?  x11 Where do we find X Windows header files?
 > /usr/X11R6/include Where do we find X Windows libraries?
 > /usr/X11R6/lib Compiling in support for XAUTH.  Compiling in
 > support for XPM.  Compiling in support for GIF image conversion.
 > Compiling in support for Berkeley DB.  Using the Lucid menubar.
 > Using the Lucid scrollbar.  Using the Athena dialog boxes.
 > Compiling in extra code for debugging.

 > Besides the errno problem which has already been reported, I had to
 > define _GNU_SOURCE in floatfns.c (before inclusion of any file!)
 > since glibc says in math.h (and those defines are need for
 > floatfns.c!):
 --------------------->
 > #ifdef __USE_SVID /* In SVID error handling, `matherr' is called
 > with this description of the exceptional condition.  */ struct
 > exception { int type; char *name; double arg1; double arg2; double
 > retval; };

 > extern int __matherr __P ((struct exception *)); extern int matherr
 > __P ((struct exception *));

 > #define X_TLOSS 1.41484755040568800000e+16

 > /* Types of exceptions in the `type' field.  */ #define DOMAIN 1
 > #define SING 2 #define OVERFLOW 3 #define UNDERFLOW 4 #define TLOSS
 > 5 #define PLOSS 6

 > /* SVID mode specifies returning this large value instead of
 > infinity.  */ #define HUGE FLT_MAX #include <float.h> /* Defines
 > FLT_MAX.  */

 > #endif <--------------------- instead of _GNU_SOURCE I could have
 > defined _SVID_SOURCE, since both _SVID_SOURCE ISO C, POSIX, and
 > SVID things.


 > in gmalloc.c, line 357, I had to comment out the definition of
 > __getpagesize, since __getpagesize is defined in <unistd.h>: #if
 > !defined(__GLIBC__) extern size_t __getpagesize __P ((void));
 > #endif

 > in configure, l.1548 I had to declare:
 > CPPFLAGS_MAKEFILEGEN="-D__LDBL_UNION__" # we normally do not need
 > any extra flags

 > because I found: union __convert_long_double { unsigned
 > __convert_long_double_i[4]; long double __convert_long_double_d; };

 > in my Makefiles (lib-src/Makefile):-(.

 > the following codefragment in
 > /usr/lib/gcc-lib/i486-linux/2.7.2.1/include/float.h was responsible
 > for the junk: #ifndef __LDBL_UNION__ #define __LDBL_UNION__ union
 > __convert_long_double { unsigned __convert_long_double_i[4]; long
 > double __convert_long_double_d; }; #endif

 > I did not investigate the problem further and just made the above
 > hack.

 > The first few seconds running the beta did not show any further
 > problems!

 > Andreas -- Andreas Jaeger aj@arthur.pfalz.de
 > jaeger@informatik.uni-kl.de Altenwoogstr. 31 67655 Kaiserslautern,
 > Germany Phone +49 631 3403051 Fax/Modem +49 631 3403052
 > http://www.student.uni-kl.de/~ajaeger/



--
Dinesh Somasekhar

