Date: Tue, 25 Apr 2000 23:03:57 -0700 (PDT)
From: Mo DeJong <[EMAIL PROTECTED]>
How would people feel about the following patch? It sort of fixes
AC_C_BIGENDIAN in the sense that it no longer errors out.
I am not sure how we can detect the system's endian ordering
without actually running a program, so this is a tempory
suggested fix until a beter one comes along.
Index: aclang.m4
===================================================================
RCS file: /cvs/autoconf/aclang.m4,v
retrieving revision 1.6
diff -u -r1.6 aclang.m4
--- aclang.m4 2000/04/11 12:00:13 1.6
+++ aclang.m4 2000/04/26 05:59:47
@@ -1003,7 +1003,7 @@
} u;
u.l = 1;
exit (u.c[sizeof (long) - 1] == 1);
-}], ac_cv_c_bigendian=no, ac_cv_c_bigendian=yes)
+}], ac_cv_c_bigendian=no, ac_cv_c_bigendian=yes,
ac_cv_c_bigendian=unknown)
fi])
if test $ac_cv_c_bigendian = yes; then
AC_DEFINE(WORDS_BIGENDIAN, 1,
This only helps if a configure script explicitly checks
ac_cv_c_bigendian. Most presumably do not; that is not part of the
documented interface to AC_C_BIGENDIAN. Therefore, this will silently
break otherwise working configure scripts with building with a
cross-compiler.
I think adding an optional argument to AC_C_BIGENDIAN is the way to
go. That does not cause anything to silently break, but it makes it
possible to write a configure script which uses AC_C_BIGENDIAN and
supports cross-compilation (presumably by testing at runtime).
(Of course, I tend to think that a properly written program does not
need to know the endianness at configuration time. For example, BFD
does not.)
Ian
