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.

James