Boost C++ Libraries: Ticket #7516: Define endianity for ARM

attachment set

Wed, 17 Oct 2012 09:28:45 GMT

attachment → boost.endian.arm.patch

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

version changed; owner set

viboes — Mon, 22 Oct 2012 17:30:41 GMT

owner set to John Maddock
version Boost 1.52.0 → Boost 1.51.0

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.

status changed; resolution set

John Maddock — Mon, 22 Oct 2012 17:47:43 GMT

status new → closed
resolution → fixed

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

John Maddock — Mon, 22 Oct 2012 18:12:53 GMT

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

Mon, 22 Oct 2012 19:25:08 GMT

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 — Sat, 09 Feb 2013 14:09:27 GMT

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 — Sat, 09 Feb 2013 14:17:30 GMT

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 — Sat, 09 Feb 2013 14:27:42 GMT

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