[tz] A small first step in merging NetBSD changes into tzcode

[Robert Elz]

    Date:        Wed, 4 Jan 2023 17:03:05 -0800
    From:        Paul Eggert via tz <tz at iana.org>
    Message-ID:  <685340cb-2787-f727-8afe-02dcab231789 at cs.ucla.edu>

I'm not Christos, who maintains tzcode for NetBSD, but perhaps
I can help...


  | NetBSD has some gimmicks to deal with old binaries with
  | 32-bit time_t (is that still relevant?)

Yes.    Just like windows still runs msdos applications,
NetBSD runs binaries (even in a.out format) compiled in
the 90's, including ones which predate 64 bit time_t.

  | NetBSD which used a NetBSD-specific function, and recoded that in 
  | standard POSIX by installing the attached patch into tzdb.

I'd hardly call perror() NetBSD specific, it has been in unix
since the dark ages.

But, as POSIX seems to have dropped it, replacing it seems sane.
But I wouldn't to it the way you have, replacing each call to
perror with a bunch of code (for error handling in situations
which realistically should never occur), instead simply add a
conditionally compiled perror() function, which can be used
on systems with a libc without it (if you can find one) or
where that function is deficient in some important way.

  | Unfortunately the build instructions for NetBSD, which say to 
  | run this to build on (say) Fedora x86-64:

  |    # https://www.netbsd.org/docs/guide/en/chap-build.html#chap-build-release
  |    ./build.sh -U -u -j4 -m amd64 -O ~/obj release

Those instructions are for someone wanting to build NetBSD,
and do rather more than what you really need.  More below.

  | do not seem to build a zdump command.

Are you sure?   It certainly builds for me.   You should
find it in usr/sbin/zdump (zic is also there).  Of course
those binaries only run on NetBSD.   If you were looking
for a "tools" version, as is created for zic, then no, there
will not be one of those.  We only build tools for things
needed to use during the build, and zdump is not needed for
that.

  | And I'm a little puzzled about how to build incrementally

The simple answer is just to run it again.   Anything that
does not need rebuilding won't be, and if your aim  is to
minimize the time you spend fiddling with details, whichh
it probably should be, then that is optimal (more computer
time used, less of yours).    On the other hand, if you'd
like to become more familiar with NetBSD, which can be a
rewarding experience, then there are othher ways, which
we can go into if applicable.

  | What I really want to do is just compile the stuff in
  | netbsd/src/lib/libc/time without compiling anything else.

You almost certainly don't, or not  if the objective is
to discover whether things build on NetBSD.  But if you
have already done the build.sh release, then you have thhe
environment already that would let you come close (if you
want to spend the time learning how0.

Two things however, first that directory is just a part
of libc, and is not set up to be built standalone.
You'd need to build in src/lib/libc instead.

And second, that only builds libc, if you wand zdump (or
zic) you'd need to build in src/usr.sbin/zdump (or
src/usr.sbin/zic).   NetBSD never builds multiple "products"
from one source directory.

What I would do however is replace "release" on the build.sh
commannd line with "build".   You don't need kernels, or
distribution tgz (or tbz or whatever they are this week) files,
or boot images, or any of that, all if which (except the
kernels) all needs to be redone for even the smallest change.
That,  on a reasonable system, after the first time (and
building release counts) should be just about quick enough.
Not as quick as just building only what you know needs to
be built, everything has ti be checked, just in case, but
unless you‘re going to be spending a lot of time on this,
and have nothing else you could usefully do in the few
minutes it takes for an incremental build (the -u option)
[how many depends upon your system] then that is the
best solution.

kre