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

[Jonathan Leffler]

The current edition of POSIX defines error() for compatibility with the C
standard if nothing else.  No future directions are specified so it is not
expected to go away (was not expected to go away in 2018 when the current
version of POSIX was defined).

See: https://pubs.opengroup.org/onlinepubs/9699919799/functions/error.html

Do you have a source for asserting otherwise?

-=JL=-


On Wed, Jan 4, 2023 at 23:35 Robert Elz via tz <tz at iana.org> wrote:

>     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
>
-- 
Jonathan Leffler <jonathan.leffler at gmail.com>  #include <disclaimer.h>
Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20230104/bbc2f5a4/attachment-0001.html>