Define endianity for ARM

[Jan Hudec <bulb@…>]

There are two cases here.

1. GCC and Clang define __ARMEL__ on little-endian ARM and __ARMEB__ on big-endian ARM, so if either is defined, use it.
2. Visual C++ for WinCE target (not sure about ARM version of Win8 yet) however does not define absolutely anything specific. It defines __ARM__ and ARM, but that might be defined in other compilers on big-endian too and _M_ARM one would expect in analogy to _M_X64 and similar is not defined. However there are no big-endian Windows API implementations at all, so the attached patch simply defaults to little-endian if _WIN32 is defined.

Note: The attached patch is minimal to get things to work, but the various _M_* defines can probably be excluded from the condition if they get covered by _WIN32.

[Jan Hudec <bulb@…>]

Patch (-p1, non-tortoise) fixing endianity detection for WinCE (and Windows 8 for ARM, probably)

[viboes]

Which library are you using that makes use of this internal file?

John, I've assigned this ticket to you as you are the last that updated the file. If you agree with the modification I could apply it myself.

[John Maddock]

(In [81047]) Fix up for Arm. Fixes #7516.

[John Maddock]

(In [81048]) Fix stray whitespace in previous commit. Refs #7516.

[Jan Hudec <bulb@…>]

Which library are you using that makes use of this internal file?

After update from 1.43 to 1.51 something in Boost.Test appears to have pulled it in.

Thanks for fixing.

[anonymous]

this change is not yet in 1.52.0.

since i don't use glibc (first check, which would use endian.h), my armel device was not detected correctly.

modern gcc's (iirc 4.4+) provide __BYTE_ORDER__ so the code should do the following:

#if defined(__GNUC__) && defined(__BYTE_ORDER__)
# if __BYTE_ORDER__ == __LITTLE_ENDIAN__
...
#elif defined(__GLIBC__)
#include <endian.h>
#else
... eternally incomplete cpu-specific ifdef hell here
#endif

[anonymous]

btw, this file is used by something during compilation of boost. so using boost 1.52.0, linux with musl libc, and armel cpu, compilation of boost fails with an #error.

[anonymous]

just tested, it's gcc 4.6+ that provides __BYTE_ORDER__