On Wed, Aug 13, 2008 at 08:19:03PM -0600, Eric Blake wrote:
> According to Peter O'Gorman on 8/13/2008 12:13 PM:
> | Hi,
> |
> | "checking whether byte ordering is bigendian... universal" is not the
> | correct answer on powerpc-ibm-aix. The question is not really correct
> | either (yes/no question, answer is neither yes nor no), but that is
> | beside the point.
> |
> | As far as I know, it is only possible to built differently endian output
> | on Mac OS X with Apple's gcc. Would a patch to limit the check for
> | universal to when __APPLE_CC__ is defined be accepted?
>
> The brokenness of AC_C_BIGENDIAN has been known for some time now, still
> without a patch.  At this point, any approach is better than none, so it
> might be worth posting your ideas.
>

Ok. This should still "work" for universal builds.

[Only lightly tested though.]

Peter
-- 
Peter O'Gorman
[EMAIL PROTECTED]
>From 62fb792c746a31c56b98dc6e89c5c0793f2b811f Mon Sep 17 00:00:00 2001
From: Peter O'Gorman <[EMAIL PROTECTED]>
Date: Thu, 14 Aug 2008 01:12:21 -0500
Subject: [PATCH] Limit AC_C_BIGENDIAN univeral checks to Mac OS X.

* lib/autoconf/c.m4 (AC_C_BIGENDIAN): Limit the check to __APPLE_C__ with 
possible -arch flags.
---
 ChangeLog         |    6 ++++++
 lib/autoconf/c.m4 |   32 ++++++++++++++++++++++++--------
 2 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index aa82465..867552d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2008-08-14  Peter O'Gorman  <[EMAIL PROTECTED]>
+
+       Limit AC_C_BIGENDIAN univeral checks to Mac OS X.
+       * lib/autoconf/c.m4 (AC_C_BIGENDIAN): Limit the check to
+       __APPLE_C__ with possible -arch flags.
+
 2008-08-12  Eric Blake  <[EMAIL PROTECTED]>
 
        Optimize m4_bmatch.
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index ffaa06e..335a9c6 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1399,11 +1399,20 @@ fi
 AC_DEFUN([AC_C_BIGENDIAN],
 [AH_VERBATIM([WORDS_BIGENDIAN],
 [/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
-   significant byte first (like Motorola and SPARC, unlike Intel and VAX). */
-#if defined __BIG_ENDIAN__
-# define WORDS_BIGENDIAN 1
-#elif ! defined __LITTLE_ENDIAN__
-# undef WORDS_BIGENDIAN
+   significant byte first (like Motorola and SPARC, unlike Intel). */
+#if defined AC_APPLE_UNIVERSAL_BUILD
+# if defined __BIG_ENDIAN__
+#  define WORDS_BIGENDIAN 1
+# else
+  /* This is not really correct, but there is little that we can do about
+   * it, #undef WORDS_BIGENDIAN would have some value substituted by
+   * config.status, not necessarily the correct one. */
+#  define WORDS_BIGENDIAN 0
+# endif
+#else
+# ifndef WORDS_BIGENDIAN
+#  undef WORDS_BIGENDIAN
+# endif
 #endif])dnl
  AC_CACHE_CHECK([whether byte ordering is bigendian], [ac_cv_c_bigendian],
    [ac_cv_c_bigendian=unknown
@@ -1411,12 +1420,18 @@ AC_DEFUN([AC_C_BIGENDIAN],
       [# See if __BIG_ENDIAN__ or __LITTLE_ENDIAN__ is defined.
        AC_COMPILE_IFELSE(
         [AC_LANG_SOURCE(
-           [[#if ! (defined __BIG_ENDIAN__ || defined __LITTLE_ENDIAN__)
-              neither is defined;
+           [[#ifndef __APPLE_CC__
+              not a universal capable compiler 
             #endif
             typedef int dummy;
            ]])],
-        [ac_cv_c_bigendian=universal])],
+        [
+       # Check for potential -arch flags it is not universal unless
+       # there are some -arch flags, note that *ppc* also matches
+       # ppc64. This check is also rather less than ideal.
+       case "${CC} ${CFLAGS} ${CPPFLAGS} ${LDFLAGS}" in  #(
+         *"ppc"*|*"i386"*|*"x86_64"*) ac_cv_c_bigendian=universal;;
+       esac])],
       [AC_DIAGNOSE([obsolete], [AC_C_BIGENDIAN suggests AC_CONFIG_HEADERS])])
     if test $ac_cv_c_bigendian = unknown; then
       # See if sys/param.h defines the BYTE_ORDER macro.
@@ -1521,6 +1536,7 @@ AC_DEFUN([AC_C_BIGENDIAN],
    no)
      $2 ;; #(
    universal)
+     AC_DEFINE([AC_APPLE_UNIVERSAL_BUILD],1,[Define if building universal])
      $4 ;; #(
    *)
      m4_default([$3],
-- 
1.5.4.1

Reply via email to