building for sandbox, warning: "__BIG_ENDIAN" is not defined
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.
am i reading that correctly? is there a proper way to handle
endianness that doesn't generate a preprocessor warning? thanks.
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Quoted 19 lines · Robert P. J. Day
perhaps showing my ignorance of how big vs little endian should be
implemented, but in configuring and building the sandbox version, i get:...
CCcommon/environment.o
In file included fromcommon/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 theenvfs.hheader contains the preprocessor checking:#ifndef
__BYTE_ORDER
#error "No byte order defined in__BYTE_ORDER"
#endif
Quoted 8 lines
#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_ENDIANor__BIG_ENDIANwon'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.
Sascha
Signature · 9 lines
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 | _______________________________________________ barebox mailing list [email protected] http://lists.infradead.org/mailman/listinfo/barebox
Quoted 40 lines · Sascha Hauer
Quoted 24 lines · Robert P. J. Day
perhaps showing my ignorance of how big vs little endian should be
implemented, but in configuring and building the sandbox version, i get:...
CCcommon/environment.o
In file included fromcommon/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 theenvfs.hheader 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 ...Quoted 4 lines
clearly(?), depending on which endianness is being used, one or
the other of__LITTLE_ENDIANor__BIG_ENDIANwon'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_ENDIAN1234
#define__BIG_ENDIAN4321In 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...
Quoted 8 lines
This part of
include/envfs.his copied frominclude/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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Quoted 51 lines · Robert P. J. Day
Quoted 40 lines · Sascha Hauer
Quoted 24 lines · Robert P. J. Day
perhaps showing my ignorance of how big vs little endian should be
implemented, but in configuring and building the sandbox version, i get:...
CCcommon/environment.o
In file included fromcommon/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 theenvfs.hheader 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 ...Quoted 4 lines
clearly(?), depending on which endianness is being used, one or
the other of__LITTLE_ENDIANor__BIG_ENDIANwon'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_ENDIAN1234
#define__BIG_ENDIAN4321In 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...
Quoted 8 lines
This part of
include/envfs.his copied frominclude/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.
Quoted 3 lines
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
Signature · 9 lines
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 | _______________________________________________ barebox mailing list [email protected] http://lists.infradead.org/mailman/listinfo/barebox