building for sandbox, warning: "__BIG_ENDIAN" is not defined

Sascha Hauer s.hauer at
Wed Dec 23 04:58:34 EST 2009

On Tue, Dec 22, 2009 at 03:56:55PM -0500, Robert P. J. Day wrote:
>   perhaps showing my ignorance of how big vs little endian should be
> implemented, but in configuring and building the sandbox version, i
> get:
> ...
>   CC      common/environment.o
> In file included from common/environment.c:37:
> include/envfs.h:47:23: warning: "__BIG_ENDIAN" is not defined
> ...
>   this isn't surprising since, as i read it, because this is x86_64,
> it's the little-endian headers that are included, but the envfs.h
> header contains the preprocessor checking:
> #ifndef __BYTE_ORDER
> #error "No byte order defined in __BYTE_ORDER"
> #endif
> ... snip ...
> #elif __BYTE_ORDER == __BIG_ENDIAN
> ... snip ...
>   clearly(?), depending on which endianness is being used, one or the
> other of __LITTLE_ENDIAN or __BIG_ENDIAN won't be defined, right?  so,
> no matter what, *one* of those tests is going to generate a warning.

Hm, in glibc both are defined like this:

#define __LITTLE_ENDIAN 1234
#define __BIG_ENDIAN    4321

In the kernel (and barebox too) only one of them is defined depending on
the endianess. I wonder why we do not define both, too.

Digging a bit further...

This part of include/envfs.h is copied from include/cramfs/cramfs_fs.h.
The cramfs header file is copied from U-Boot, but as the U-Boot guys
found out cramfs is always in host order and thus does not need byteswap
functions (see
But that's another story, I think we should keep the environment in
little endian order to be able to generate a envfs image on the compile


Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 |  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

More information about the barebox mailing list