From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 6 Sep 2001 13:01:06 -0700 From: andrew may To: Tom Rini Cc: acmay@acmay.homeip.net, Dan Malek , John Tyner , linuxppc-commit@source.mvista.com, linuxppc-embedded@lists.linuxppc.org Subject: Re: patch for mktree.c on cross compiles Message-ID: <20010906130106.L14548@ecam.san.rr.com> References: <20010905120613.I14548@ecam.san.rr.com> <3B968E75.A63F26EA@mvista.com> <20010905212050.K18940@cpe-24-221-152-185.az.sprintbbd.net> <20010905223903.D621@sink.san.rr.com> <20010906075542.A21172@cpe-24-221-152-185.az.sprintbbd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20010906075542.A21172@cpe-24-221-152-185.az.sprintbbd.net> Sender: owner-linuxppc-embedded@lists.linuxppc.org List-Id: On Thu, Sep 06, 2001 at 07:55:42AM -0700, Tom Rini wrote: > On Wed, Sep 05, 2001 at 10:39:03PM -0700, acmay@acmay.homeip.net wrote: > > On Wed, Sep 05, 2001 at 09:20:50PM -0700, Tom Rini wrote: > > > On Wed, Sep 05, 2001 at 04:43:33PM -0400, Dan Malek wrote: > > > > andrew may wrote: > > > > > I would think everything in arch/ppc/boot/utils should be checked > > > > > for endian problems on cross compiles. > > > > > > > > Are the network-host macros the right things to use? That's what > > > > always comes to mind for me, but I suspect there is a more standard > > > > set of macros from 'endian.h' or something........If it's OK with > > > > everyone I'll check it in, but it does look kind of weird. > > > > > > Well, after some quick digging, here's what I found. If we include > > > , and deal with some __'s, which are exported outside > > > > One problem with trying this is that will only be for > > the target, not the compiling host. I think mktree should stick with > > standard userspace include headers and stay away from kernel headers. > > Er. No, _should_ be a userspace header. At least on > Linux.. For BSD (and Linux with _USE_BSD) we can use sys/types.h and get > back a __BYTE_ORDER, I _think_... It seems that is one of the "shared" headers between glibc and the kernel. Hasn't Linus wanted the glibc people to do there own headers for ages. Either way it seems that htonl gets mapped down __cpu_to_be32() in linux/byteorder/generic.h. So that even thought it seems strange to use the "network" functions it does seem to be OK. We can only hope people don't have bad /usr/include/[asm][linux] symlinks. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/