From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from [2001:6f8:1178:4:290:27ff:fe1d:cc33] (helo=metis.ext.pengutronix.de) by casper.infradead.org with esmtps (Exim 4.69 #1 (Red Hat Linux)) id 1NNOoZ-00084x-VA for barebox@lists.infradead.org; Wed, 23 Dec 2009 10:51:37 +0000 Date: Wed, 23 Dec 2009 11:50:33 +0100 From: Sascha Hauer Message-ID: <20091223105033.GR15126@pengutronix.de> References: <20091223095834.GQ15126@pengutronix.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: barebox-bounces@lists.infradead.org Errors-To: barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org Subject: Re: building for sandbox, warning: "__BIG_ENDIAN" is not defined To: "Robert P. J. Day" Cc: "U-Boot Version 2 (barebox)" 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 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox