Bug 449944

Summary: AC_C_BIGENDIAN macro is badly broken
Product: [Fedora] Fedora Reporter: Adam Tkac <atkac>
Component: autoconfAssignee: Stepan Kasal <kasal>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: ovasik
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Whiteboard:
Fixed In Version: 2.62-4.fc10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-05 18:35:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 453566    
Attachments:
Description Flags
testcase none

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
access)

How reproducible:
always

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]
testcase

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
action-if-unknown.

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__
#  define WORDS_BIGENDIAN 1
#endif
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