From xemacs-m  Tue Feb  4 18:26:06 1997
Received: from birdland.rhein-neckar.de (root@birdland.rhein-neckar.de [193.197.88.3])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id SAA14624
	for <xemacs-beta@xemacs.org>; Tue, 4 Feb 1997 18:26:01 -0600 (CST)
Received: from mips.pfalz.de (uucp@localhost) by birdland.rhein-neckar.de (8.8.3/8.8.3) with BSMTP id BAA24850 for xemacs.org!xemacs-beta; Wed, 5 Feb 1997 01:08:20 +0100 (MET)
Received: from cthulhu.pfalz.de by mips.pfalz.de with bsmtp
	(Smail3.1.29.1 #6) id m0vru5s-000CnNC; Wed, 5 Feb 97 00:16 CET
Received: from arthur.pfalz.de by cthulhu.pfalz.de
	via rsmtp with bsmtp
	id <m0vrslp-000CFwC@cthulhu.pfalz.de>
	for <xemacs-beta@xemacs.org>; Tue, 4 Feb 1997 22:51:17 +0100 (MET)
	(Smail-3.2 1996-Jul-4 #20 built 1996-Oct-4)
Received: by arthur.pfalz.de
	via smail with stdio
	id <m0vrscS-0001jRC@arthur.pfalz.de>
	for xemacs-beta@xemacs.org; Tue, 4 Feb 1997 21:41:36 +0000 (GMT)
	(Smail-3.2 1996-Jul-4 #6 built 1996-Oct-4)
Message-Id: <m0vrscS-0001jRC@arthur.pfalz.de>
Date: Tue, 4 Feb 1997 21:41:36 +0000 (GMT)
From: Andreas Jaeger <aj@arthur.pfalz.de>
To: xemacs-beta@xemacs.org
Subject: GNU libc 2.0 & xemacs-19.15-beta92, more problems & success!
Reply-To: jaeger@informatik.uni-kl.de


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/

