Subject: Re: Recent changes to sys/endian.h break eVC
To: None <email@example.com>
From: James Chacon <firstname.lastname@example.org>
Date: 02/28/2005 18:10:42
On Mon, Feb 28, 2005 at 06:45:17AM +0300, Valeriy E. Ushakov wrote:
> On Sun, Feb 27, 2005 at 21:33:51 -0600, James Chacon wrote:
> > On Sun, Feb 27, 2005 at 09:55:54PM +0300, Valeriy E. Ushakov wrote:
> > > sys/endian.h now has routines to encode/decode big- and little-endian
> > > multi-octet values to/from an octet stream. The problem is that that
> > > 64-bit routines use constants with ...ULL suffix, and embedded Visual
> > > C (that we use to compile hpcboo.exe - a WinCE boot loader for
> > > NetBSD/hpc* ports) is old enough to not know anything about ULL.
> > If it's a host tool, why does it need our endian.h? Provide a local
> > one in it's source tree if need be.
> Well, hpcboot is an interesting beast. "Its source tree" is actually
> our source tree: sys/arch/hpc/stand/hpcboot :). It uses libsa and
> libz. It's a boot loader, but it's not really standalone, as it's a
> WinCE program.
> A private sys/endian.h is probably the easiest way in this particual
> case, but a change like that in, say, libsa would have more impact.
It should probably still have a private one then or at least file a PR
for this around libnbcompat not providing enough here.
> Re host-tool'ness. Host tools *will* use our sys/endian.h if the host
> platform doesn't provide a working one. Actually, I've been thinking
> about forcing the use of in-tree sys/endian.h instead of the host's
> one. E.g. on FreeBSD 4.x our tree will not build with the system's
> sys/endian.h, so I always build with ac_cv_header_sys_endian_h=no to
> force the use of the in-tree version.
Ummm...I've cross built from freebsd 4.x as recently as a month ago. Have
you tried anytime recently w/o local hacks?
If it doesn't work, file PR's and it'll get fixed.