|Summary:||AC_C_BIGENDIAN macro is badly broken|
|Product:||[Fedora] Fedora||Reporter:||Adam Tkac <atkac>|
|Component:||autoconf||Assignee:||Stepan Kasal <kasal>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||2.62-4.fc10||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-07-05 18:35:58 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
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