Bug 449944 - AC_C_BIGENDIAN macro is badly broken
AC_C_BIGENDIAN macro is badly broken
Product: Fedora
Classification: Fedora
Component: autoconf (Show other bugs)
ppc64 Linux
low Severity low
: ---
: ---
Assigned To: Stepan Kasal
Fedora Extras Quality Assurance
Depends On:
Blocks: 453566
  Show dependency treegraph
Reported: 2008-06-04 08:31 EDT by Adam Tkac
Modified: 2013-04-30 19:39 EDT (History)
1 user (show)

See Also:
Fixed In Version: 2.62-4.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-05 14:35:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
testcase (55.40 KB, application/x-bzip2)
2008-06-04 08:34 EDT, Adam Tkac
no flags Details

  None (edit)
Description Adam Tkac 2008-06-04 08:31:18 EDT
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

How reproducible:

Steps to Reproduce:
see attached testcase
Actual results:
"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)

Expected results:
AC_C_BIGENDIAN as in 2.61

Additional info:
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.
Comment 1 Adam Tkac 2008-06-04 08:34:06 EDT
Created attachment 308336 [details]

Try compile attached testcase on ppc64, it fails. With older autoconf (2.61)
should be successful
Comment 2 Adam Tkac 2008-06-04 09:07:47 EDT
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.
Comment 3 Stepan Kasal 2008-06-04 11:27:54 EDT
> 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.

I agree with you that this is a bug.

The idea was that config.h contains
#ifdef __BIG_ENDIAN__
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.
Comment 4 Stepan Kasal 2008-07-05 14:35:58 EDT
autoconf-2.62-4.fc10 contains patch which disables the unfortunate attempt to
support universal binaries.
Comment 5 Stepan Kasal 2008-07-08 13:43:08 EDT
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

Note You need to log in before you can comment on or make changes to this bug.