Bug 449944 - AC_C_BIGENDIAN macro is badly broken
Summary: AC_C_BIGENDIAN macro is badly broken
Alias: None
Product: Fedora
Classification: Fedora
Component: autoconf
Version: rawhide
Hardware: ppc64
OS: Linux
Target Milestone: ---
Assignee: Stepan Kasal
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 453566
TreeView+ depends on / blocked
Reported: 2008-06-04 12:31 UTC by Adam Tkac
Modified: 2013-04-30 23:39 UTC (History)
1 user (show)

Fixed In Version: 2.62-4.fc10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-07-05 18:35:58 UTC
Type: ---

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

Description Adam Tkac 2008-06-04 12:31:18 UTC
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 12:34:06 UTC
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 13:07:47 UTC
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 15:27:54 UTC
> 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 18:35:58 UTC
autoconf-2.62-4.fc10 contains patch which disables the unfortunate attempt to
support universal binaries.

Comment 5 Stepan Kasal 2008-07-08 17:43:08 UTC
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.