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.

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.

PS: Long term, it'd be interesting to make hpcboot compiled with
in-tree gcc.

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen