Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#7516 closed Patches (fixed)

Define endianity for ARM

Reported by: Jan Hudec <bulb@…> Owned by: John Maddock
Milestone: To Be Determined Component: None
Version: Boost 1.51.0 Severity: Problem
Keywords: Cc:

Description

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.

Attachments (1)

boost.endian.arm.patch (889 bytes) - added by Jan Hudec <bulb@…> 6 years ago.
Patch (-p1, non-tortoise) fixing endianity detection for WinCE (and Windows 8 for ARM, probably)

Download all attachments as: .zip

Change History (8)

Changed 6 years ago by Jan Hudec <bulb@…>

Attachment: boost.endian.arm.patch added

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

comment:1 Changed 6 years ago by viboes

Owner: set to John Maddock
Version: Boost 1.52.0Boost 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.

comment:2 Changed 6 years ago by John Maddock

Resolution: fixed
Status: newclosed

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

comment:3 Changed 6 years ago by John Maddock

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

comment:4 in reply to:  1 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by 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

comment:6 Changed 6 years ago by 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.

comment:7 Changed 6 years ago by anonymous

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

Note: See TracTickets for help on using tickets.