Date:        Wed, 23 Jul 2003 21:08:51 +1000
    From:        Luke Mewburn <lukem@NetBSD.org>
    Message-ID:  <20030723110851.GG13935@mewburn.net>

  | Actually, stat(1) greatly simplified how symlink & hardlinks are
  | installed by bsd.links.mk, and the symlink support in bsd.obj.mk
  | and bsd.kinc.mk.  So it *is* useful as a hostprog,

That's not a correct conclusion - what you mean is that something to
simplify how links are handled would be a useful hostprog.   It doesn't
need to be stat for this purpose.

  | Yes, but that doesn't preclude stat being it.

No, it could be stat - provided someone is willing to do the work
to make a truly portable version of it.

All of the hostprogs should be portable (in that, the code that implements
them needs to be portable, not that the function provided by the program
needs to be available everywhere).   Stat happens to be (I think the first)
very NetBSD (*BSD perhaps) specific program that's been made a HOSTPROG.

That is no criticsm of stat - it is how it should be (the same issues
would arise if someone felt a need to make NetBSD's ps, or vmstat, or
something like that, into a HOSTPROG).

  | With all of our other host tools, we leverage off the existing code.
  | I don't see the "win" in changing this now for minor asthetic reasons,
  | and also at the expense of "separate code to maintain"...

Fine - but it isn't a "minor asthetic reason" - you need to make stat
compile and run on HPUX. AIX, ... everything that pretends to be POSIX
and for which an ANSI C compiler exists, in order for it to be useful
as a HOSTPROG.   That's certainly possible - the question is which is
easier long term.

  | Well, in that case, the prior behaviour was buggy anyway, because there
  | were other stat fields (%f - st_flags - springs to mind) that were NOT
  | in those format strings.

That should be fixed as well.

  | Or we can just make %B and %f and other "non standard" stuff continue
  | to error out in the hostprog version (which is acceptable because we
  | know how we are using the hostprog), or print "empty" results for
  | unsupport flags.

Yes, anything.

  | However, many people were running into build issues on non-netbsd-current
  | platforms,

yes, I understand that, I am not asking that the fix you committed be
removed.

I had exactly that problem, my build system has a 1.6L (I think) userland.
(Doesn't have the birthtime nonsense anyway), so I struck this problem
last night (first build I'd done in a week).   I "solved" the problem
by simply removing the st_birthtime code from stat.c (#if 0) while the tools
were being built and installed, and then replacing it before the build got to
actually compiling ${DESTDIR}/usr/bin/stat

But that's hardly a workable solution to offer anyone... (I knew this
would quickly get fixed, so didn't look for a better solution).

But now -current should compile on NetBSD 1.6.1 (and older -current)
again you will soon get people complaining that it won't cross-compile
from other systems.   Fixing "issues" with stat portability is likely
to take forever, unless a long term solution is found (and again, I
suggest using something that does only what the build scripts/makefiles
actually need it to do - using the stat.c source file with the HOSTPROG
define to eliminate almost everything, or using separate sources)

kre