Fallback to compiler defines when __BYTE_ORDER is not available

[kulikjak]

On some systems (I tested it on Oracle Solaris and FreeBSD), __BYTE_ORDER, __LITTLE_ENDIAN and __BIG_ENDIAN from arpa/inet.h are not available, which can cause failures on big endian systems (because little endian is the default). This adds a fallback to common compiler defines in those cases.

Addresses issues raised in #495.

[methane]

After how __BYTE_ORDER and __BYTE_ORDER__ are used in world, I prefer using just __BYTE_ORDER__.
Please make it simple.

[kulikjak]

Done, thanks!

[methane]

Remove this too:

#else
#include <arpa/inet.h>  /* __BYTE_ORDER */

[kulikjak]

I missed that - updated and retested.

[klemensn]

This fix is required on OpenBSD/sparc64 to unbreak borgbackup 1.2.2 at runtime, see borgbackup/borg#6149 (comment) for details.

[klemensn]

msgpack-python 1.0.4 regression tests pass 100% with and without this fix on OpenBSD/sparc64.
Here is an example test run of 1.0.4 without this fix: https://gist.github.com/936496c1bea568a0f741ae9b3ec54d39

Passing tests but failing runtime consumers at the same time suggests a lack of endianess coverage.

[klemensn]

Remove this too:

#else
#include <arpa/inet.h>  /* __BYTE_ORDER */

Can you elaborate why?

This include is required by ntohs(3) later in the same file:
https://github.com/msgpack/msgpack-python/pull/513/files#diff-5c123c916851553e85829468dc2fadee6b1ed6edda136c8d544d5a0eaf594d99R90

Accidentially, it seems, this builds fine on OpenBSD, but breaks at least in Ubuntu 20.04, see
borgbackup/borg#7181 (comment) and borgbackup/borg@e79986b.

[methane]

#514