[AC21.4] fix Berkeley db autodetection on FreeBSD
The patchlet below contains FreeBSD-specific hacks. You just know
this isn't going to really fix the problem, since it will re-occur on
FooBSD and random other OSes.
What to do? I've known for a while that there's a problem with
XEmacs' attempt to use the new semi-standard fixed-size integral types
like uint8_t and Berkeley DB's attempt to do the same. A real fix is
going to involve looking at all of the Berkeley DB version's code for
detecting these types and coordinating with our own.
In retrospect, it was a mistake (mine) for XEmacs to detect and use
inttypes.h. This header file never became part of a standard (instead
stdint.h did) and implementation of these header files has been
inconsistent and slow. C99 has stdint.h, but C++97 does not. I've
not yet heard of any C compiler advertising complete C99 compliance.
Anyways, a proper fix is going to involve research, deep thought and
careful testing on multiple platforms. The below is the sort of
bandaid that I've been careful to avoid during my time as
configuration maintainer.
2003-03-03 Robert Pluim <rpluim(a)bigfoot.com>
* database.c: Don't use the u_int8_t etc typedefs on FreeBSD,
they conflict with <sys/types.h>.
Index: database.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/database.c,v
retrieving revision 1.16.2.2
diff -u -r1.16.2.2 database.c
--- database.c 2003/02/24 03:25:24 1.16.2.2
+++ database.c 2003/03/03 09:07:51
＠＠ -45,11 +45,13 ＠＠
#ifdef HAVE_INTTYPES_H
#define __BIT_TYPES_DEFINED__
#include <inttypes.h>
+#ifndef __FreeBSD__
typedef uint8_t u_int8_t;
typedef uint16_t u_int16_t;
typedef uint32_t u_int32_t;
#ifdef WE_DONT_NEED_QUADS
typedef uint64_t u_int64_t;
+#endif
#endif /* WE_DONT_NEED_QUADS */
#endif /* HAVE_INTTYPES_H */
#endif /* !(defined __GLIBC__ && __GLIBC_MINOR__ >= 1) */