From: Sascha Hauer <s.hauer@pengutronix.de>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: "U-Boot Version 2 (barebox)" <barebox@lists.infradead.org>
Subject: Re: building for sandbox, warning: "__BIG_ENDIAN" is not defined
Date: Wed, 23 Dec 2009 10:58:34 +0100 [thread overview]
Message-ID: <20091223095834.GQ15126@pengutronix.de> (raw)
In-Reply-To: <alpine.LFD.2.00.0912221552470.17516@localhost>
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.
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 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2009-12-23 9:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-22 20:56 Robert P. J. Day
2009-12-23 9:58 ` Sascha Hauer [this message]
2009-12-23 10:26 ` Robert P. J. Day
2009-12-23 10:50 ` Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091223095834.GQ15126@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=rpjday@crashcourse.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox