Re: zlib builtin bug workaround on NetBSD

[Greg Troxel <gdt%lexort.com@localhost>]

Thomas Klausner <wiz%netbsd.org@localhost> writes:

> 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.

FWIW this approach sounds good to me.