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

[Sascha Hauer]

On Wed, Dec 23, 2009 at 05:26:08AM -0500, Robert P. J. Day wrote:
> On Wed, 23 Dec 2009, Sascha Hauer wrote:
> 
> > 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
> > >
> > > #if __BYTE_ORDER == __LITTLE_ENDIAN
> > > ... 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
> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/22846) 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 host.
> 
>   soooo ... not sure what you're proposing here.  it appears that the
> warning above is just a warning, doesn't break anything so i guess it
> could be left as is, but it just looks messy.

Yes, it looks messy and we should fix this, but so far I don't know what
to do best, so I just wrote up what I found out. I tend to define both
__*_ENDIAN in any case.

Sascha


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