Re: [Failure] Xemacs 21.0.65 on Digital UNIX 4.0D with DEC C

K> I got the following error when I tried to make 21.0.65 on my DU 4.0D K> system: K> cc -c -std -fast -Demacs -I. -DHAVE_CONFIG_H -std -I/usr/local/include -I/usr/dt/include abbrev.c K> cc: Error: lisp.h, line 2451: Ill-formed parameter type list. K> int unexec (char *, char *, uintptr_t, uintptr_t, uintptr_t); K> ----------------------------^ K> gmake[1]: *** [abbrev.o] Error 1 K> gmake[1]: Leaving directory `/home/oberman/utils/xemacs-21.0.65/src' K> gmake: *** [src] Error 2 K> Configured using: K> ./configure --with-site-lisp --site-includes=/usr/local/include --without-gcc --with-gnu-make '--cflags=-std -fast' >> Sorry, this works for me on DU 4.0E. >> Please figure out why uintptr_t is not defined. >> There's code in lisp.h to make sure it is. Kev> Yes, but it looks like a bug in the inttypes.h on DU4.0D when IPv6 is Kev> installed. The problem is that IPv6 adds the file Kev> "/usr/include/inttypes.h" which previously did not exist. lisp.h Kev> includes this inttypes.h which just defines _INTTYPES_H and includes Kev> sys/inttypes.h. But sys/inttypes.h only defines uintptr_t when Kev> _INTTYPES_H is NOT defined, so it does nothing. Since inttypes.h is still undergoing standardization, it seems to be causing more problems than it solves. I propose that we stop using it. (I was the one who (mistakenly?) introduced it). We have to have our own code anyways to define intptr_t and friends, which works pretty darn well. In the real world, sizeof(void*) will always be equal to sizeof(int) or sizeof(long). Currently lisp.h has: #ifdef HAVE_INTTYPES_H #include <inttypes.h> #elif SIZEOF_VOID_P == SIZEOF_INT typedef int intptr_t; typedef unsigned int uintptr_t; #elif SIZEOF_VOID_P == SIZEOF_LONG typedef long intptr_t; typedef unsigned long uintptr_t; #elif defined(SIZEOF_LONG_LONG) && SIZEOF_VOID_P == SIZEOF_LONG_LONG typedef long long intptr_t; typedef unsigned long long uintptr_t; #else /* Just pray. May break, may not. */ typedef long intptr_t; typedef unsigned long uintptr_t; #endif Kev> I assume that this is an error as I don't think this behavior is Kev> reasonable. I worked around it by changing lisp.h to include Kev> sys/inttypes.h and this did the trick. I will contact the IPv6 folks Kev> at Compaq and see if there is a fix (or I may just do it myself). Kev> Since so few people are likely to have IPv6 installed and since it Kev> appears to clearly be a bug in the IPv6 supplied file, I don't see any Kev> reason to "fix" anything, but a caveat might be in order. (Though I'm Kev> not too sure it's worth even that.) Again, I propose we stop #including <inttypes.h> Comments? Martin