Description of problem:
AC_C_BIGENDIAN macro is badly broken. It detects that machine could run in both
endianess which is nice but completely unusable in many current programs.
C preprocessor defines correct endianess (ppc64):
$ cpp -dM /dev/null |grep ENDIAN
#define __BIG_ENDIAN__ 1
#define _BIG_ENDIAN 1
Version-Release number of selected component (if applicable):
$rpm -q autoconf
autoconf-2.62-1.fc10.noarch (ppc64 build environment, let me know if you need
Steps to Reproduce:
see attached testcase
"universal" endianess detected which means that current code which depends on
AC_C_BIGENDIAN macro is broken and/or not compilable (at least Xorg, vnc)
AC_C_BIGENDIAN as in 2.61
I don't think that "universal" endianess is useful on Linux (not sure about
other kernels) at all. In theory it is possible run little-endian binary on
big-endian kernel but who does such hacking?
If I look onto AC_C_BIGENDIAN macro definition it does simple test #if (defined
__BIG_ENDIAN__ || defined __LITTLE_ENDIAN__) => platform has universal endian. I
don't think this simple and weird test is good.
Possible fix is drop AC_C_BIGENDIAN macro and include <endian.h> header directly
but I think fix AC_C_BIGENDIAN macro is better.
Created attachment 308336 [details]
Try compile attached testcase on ppc64, it fails. With older autoconf (2.61)
should be successful
Also as written in autoconf manual:
In some cases a single run of a compiler can generate code for multiple
architectures. This can happen, for example, when generating Mac OS X universal
binary files, which work on both PowerPC and Intel architectures. In this case,
the different variants might be for different architectures whose endiannesses
differ. If configure detects this, it executes action-if-universal instead of
I don't think that our ppc64 gcc is able to produce little-endian code
especially when endianess macros are defined directly by preprocessor.
> I look onto AC_C_BIGENDIAN macro definition it does simple test
> #if (defined __BIG_ENDIAN__ || defined __LITTLE_ENDIAN__) => platform has
> I don't think this simple and weird test is good.
I agree with you that this is a bug.
The idea was that config.h contains
# define WORDS_BIGENDIAN 1
so we do not need more compilations. This is a nice optimization for the case
when AC_C_BIGENDIAN was called without parameters.
But, obviously, it breaks your test case:
AC_C_BIGENDIAN([AC_DEFINE(BIG, 1, [big])], [AC_DEFINE(LITTLE, 1, [little])])
I'll report that to bug-autoconf.
autoconf-2.62-4.fc10 contains patch which disables the unfortunate attempt to
support universal binaries.
If a configure script is affected by this bug in autoconf-2.62, you can
workaround the bug by fixing the configure script like this:
sed -i 's/ac_c_bigendian/: &/' ./configure