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

["Robert P. J. Day" <rpjday@crashcourse.ca>]

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.  so what are you
suggesting?  and maybe i'll just leave that for others higher up the
food chain to deal with.

rday
--



========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox