Re: zlib builtin bug workaround on NetBSD

[Thomas Klausner <wiz%netbsd.org@localhost>]

On Sun, Oct 19, 2025 at 10:28:18PM +0100, Taylor R Campbell wrote:
> It turns out NetBSD has been shipping with a bug in its zconf.h, part
> of zlib, that causes certain inline macros -- and potentially function
> prototypes -- to be wrong in a way that breaks the build of certain
> packages using autoconf on LP32 platforms.
> 
> PR lib/59711: "#define HAVE_UNISTD_H 1" breaks 32-bit libz
> 
> Specifically, zconf.h has logic that roughly boils down to:
> 
> #ifndef z_off_t
> #  ifdef HAVE_UNISTD_H
> #    define z_off_t	off_t
> #  else
> #    define z_off_t	long
> #  endif
> #endif
> 
> and similarly for z_ptrdiff_t.
> 
> The system library is built with z_off_t=long (i.e., without
> HAVE_UNISTD_H), but if you build a program with autoconf defining
> HAVE_UNISTD_H, that program will be built with the wrong definition of
> z_off_t in various functions and inline macros in zlib.h.
> 
> The wrong definition has different size on LP32 platforms.  On
> little-endian LP32 platforms, as long as the structure in question is
> padded, using off_t (64-bit) where you should use long (32-bit) may
> not cause too much trouble because the placement of numbers below 2^32
> coincides, but on big-endian LP32 the low bytes are in the wrong place
> so things quickly go awry as in the PR.
> 
> Of course we'll fix this in NetBSD so that it ignores HAVE_UNISTD_H
> and gives the same z_off_t with or without that macro.  But there will
> remain a problem with binary packages built against the x.0 release
> with the broken zconf.h.  I expect we can work around it in pkgsrc by
> putting the following fragment in devel/zlib/builtin.mk (plus an
> explanatory comment with references):
> 
> .    if ${OPSYS} == "NetBSD" && ${OPSYS_VERSION} < 110000
> CPPFLAGS+=	-Dz_off_t=long -Dz_ptrdiff_t=long
> CFLAGS+=	-Dz_off_t=long -Dz_ptrdiff_t=long
> .    endif
> 
> But this will also require rebuilding any packages that were already
> built against the builtin zlib -- those packages need to be revbumped.
> 
> Thoughts?

Since this probably means bumping >50% of pkgsrc, I'm slightly against
the bump (not against the fix, of course).

I suggest instead that we loudly shout that bulk builds on the
affected platforms (big-endian LP32, as I undestand you) should be
restarted from scratch.

If that's fine with you, please commit the zlib diff (or ask me to)
and then we can re-send your email with a "[HEADSUP] big-endian lp32
bulk builders" subject.
 Thomas