Eric Blake wrote:
According to Matthew Woehlke on 3/2/2007 9:33 AM:
Another option would be to leave int64_t defined as it is, but set
HAVE_INT64_T
to 0, to indicate that gnulib shouldn't use it.
Hmm... this looks like it would fix sys/stat.h (see below). I'm still
not sure I trust it. Will clock_t and fpos_t be defined correctly so as
to not break system API's using these? Will gnulib behave correctly
w.r.t. these?
We don't have access to your system, so you will have to try various
experiments. One thing that would be helpful is for you to determine how
packages will behave as though the .m4 files were fixed to already
recognize that gnulib's assumptions about long long are broken, and
therefore, from gnulib's point of view, a working long long does not exist
(leaving actual system headers to use long long to their hearts content,
unmolested by gnulib's replacement stdint.h).
Can you try 'ac_cv_type_long_long_int=no
ac_cv_type_unsigned_long_long_int=no ac_cv_type_long_long=no ./configure'
and see if that can build a working image?
(We already know this doesn't work: if configure doesn't define
HAVE_LONG_LONG_INT, then the resulting stdint.h breaks system headers.)
- what is the original definition of int64_t on this OS if gnulib is
not involved? (a macro, a typedef?)
sys/types.h has:
#ifdef __TANDEM
#define int64_t long long
#else
typedef double int64_t;
#endif
(__TANDEM is normally defined; the alternative is clearly a hack of sorts.)
So this part of stdint_.h could use an edit to not unconditionally
undefine int64_t:
#undef int64_t
#if LONG_MAX >> 31 >> 31 == 1
# define int64_t long int
#elif defined _MSC_VER
# define int64_t __int64
#elif @HAVE_LONG_LONG_INT@
# define int64_t long long int
#endif
instead, it should look like
#if LONG_MAX >> 31 >> 31 == 1
# undef int64_t
# define int64_t long int
#elif defined _MSC_VER
# undef int64_t
# define int64_t __int64
#elif @HAVE_LONG_LONG_INT@
# undef int64_t
# define int64_t long long int
#endif
Can you test (preferably independently of the earlier test) whether that
edit helps matters any? There may be further edits necessary, since later
parts of stdint_.h currently depend on whether int64_t is defined, when
they should really depend on whether int64_t is defined by gnulib (since
you've already proven that it is defined by your platform, but that gnulib
doesn't really work with 64-bit types on your platform).
Without also telling gnulib not to use 'long long', we know other things
(like gnulib's printf - of whichever flavor, I don't recall exactly
which one offhand) break.
I did this:
--- stdint_.h 2007-03-08 08:14:55.000000000 -0800
+++ ../../m4-1.4.8b-orig/lib/stdint_.h 2007-03-01 08:48:39.000000000 -0800
@@ -120,17 +120,12 @@
#define int32_t int
#define uint32_t unsigned int
+#undef int64_t
#if LONG_MAX >> 31 >> 31 == 1
-# undef int64_t
-# define GNULIB_int64_t
# define int64_t long int
#elif defined _MSC_VER
-# undef int64_t
-# define GNULIB_int64_t
# define int64_t __int64
#elif @HAVE_LONG_LONG_INT@
-# undef int64_t
-# define GNULIB_int64_t
# define int64_t long long int
#endif
@@ -169,10 +164,10 @@
#define uint_least16_t uint16_t
#define int_least32_t int32_t
#define uint_least32_t uint32_t
-#ifdef GNULIB_int64_t
+#ifdef int64_t
# define int_least64_t int64_t
#endif
-#ifdef GNULIB_uint64_t
+#ifdef uint64_t
# define uint_least64_t uint64_t
#endif
@@ -200,7 +195,7 @@
#define uint_fast16_t unsigned int_fast16_t
#define int_fast32_t long int
#define uint_fast32_t unsigned int_fast32_t
-#ifdef GNULIB_int64_t
+#ifdef int64_t
# define int_fast64_t int64_t
#endif
#ifdef uint64_t
@@ -222,7 +217,7 @@
#undef intmax_t
#if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1
# define intmax_t long long int
-#elif defined GNULIB_int64_t
+#elif defined int64_t
# define intmax_t int64_t
#else
# define intmax_t long int
@@ -269,7 +264,7 @@
#undef INT64_MIN
#undef INT64_MAX
-#ifdef GNULIB_int64_t
+#ifdef int64_t
# define INT64_MIN (~ INT64_MAX)
# define INT64_MAX INTMAX_C (9223372036854775807)
#endif
@@ -308,7 +303,7 @@
#undef INT_LEAST64_MIN
#undef INT_LEAST64_MAX
-#ifdef GNULIB_int64_t
+#ifdef int64_t
# define INT_LEAST64_MIN INT64_MIN
# define INT_LEAST64_MAX INT64_MAX
#endif
@@ -347,7 +342,7 @@
#undef INT_FAST64_MIN
#undef INT_FAST64_MAX
-#ifdef GNULIB_int64_t
+#ifdef int64_t
# define INT_FAST64_MIN INT64_MIN
# define INT_FAST64_MAX INT64_MAX
#endif
@@ -474,7 +469,7 @@
#undef INTMAX_C
#if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1
# define INTMAX_C(x) x##LL
-#elif defined GNULIB_int64_t
+#elif defined int64_t
# define INTMAX_C(x) INT64_C(x)
#else
# define INTMAX_C(x) x##L
...and I'm waiting to see if it works (did I mention this box is
god-awful slow? :-)).
Oh, and clock_t, dev_t and fpos_t are also 'long long', and 'long long'
shows up in several places in socket code (not sure if that's an issue
or not, since so far we aren't talking about any networking apps).
Shouldn't matter - gnulib can't redefine 'long long' since it occupies
multiple tokens; and as long as gnulib doesn't use long long, we shouldn't
be running afoul of your compiler's (awful) limitations.
The question was "does gnulib ever use clock_t, dev_t or fpos_t?",
particularly in reference to system headers.
--
Matthew
"There's nothing in the universe so permanent as a temporary government
agency." -- Phil Geusz
_______________________________________________
M4-discuss mailing list
M4-discuss@gnu.org
http://lists.gnu.org/mailman/listinfo/m4-discuss
