Re: sysbuild of netbsd-10 from netbsd-10 fails after upgrade of itself

At Wed, 8 Oct 2025 10:58:52 +0000 (UTC), RVP <[email protected]> wrote:
Subject: Re: sysbuild of netbsd-10 from netbsd-10 fails after upgrade of itself
>
> Defining `_POSIX_SOURCE 1' undefs `_NETBSD_SOURCE' in <sys/featuretest.h>

Well, indeed, there's the problem.  _POSIX_SOURCE is explicitly set
early in src/tools/compat/compat_defs.h, which is pulled in by
"nbtool_config.h" (and before any other #includes), and
"nbtool_config.h" is of course included in sha2.c whenever
"-DHAVE_NBTOOL_CONFIG_H=1" is given, as it is when building libnbcompat
(though it would be pulled in anyway in the libnbcompat build since the
local compat/namespace.h also includes "nbtool_config.h" unconditionally
and "namespace.h" is itself included (effectively) unconditionally in
sha2.c).

Anyway, not having _NETBSD_SOURCE defined when compiling sha2.c means
that when <sys/endian.h> is pulled in then the inline definitions for
those functions are not revealed.


When I first looked at it I ignored the '#ifdef _NETBSD_SOURCE' line
because I assumed it must be set since we're compiling NetBSD source!  I
forgot that in src/tools/compat this is forbidden.

I see this is the original change that introduced the "problem", and it
is pulled up in revision 1.31.4.1, and of course it is correct as is:

| revision 1.34
| date: 2024-09-09 11:17:14 -0700;  author: riastradh;  state: Exp;  lines: +5 -1;  commitid: MqAROERL3jXe0apF;
| sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
|
| These are non-standard extensions, so they should not be exposed by,
| e.g., _XOPEN_SOURCE=700.
|
| PR standards/57807: #include <arpa/inet.h> spuriously defines
| le32enc/be32enc/... under _XOPEN_SOURCE=700


I'm still not quite seeing how this "works" in -current.

There's a mess of discussion in PR#57807, but I still don't quite see
the fix -- anyway something seems to have been missed in the pullups for
netbsd-10 as it cannot build itself!



> When compiling sha2.c, <sys/endian.h> isn't used at all.

Well actually <sys/types.h> (which sha2.c unconditionally includes)
pulls in <machine/endian.h> which is just a wrapper to pull in
<sys/endian.h>, so <sys/endian.h> _is_ used (implicitly) in sha2.c.


--
					Greg A. Woods <[email protected]>

Kelowna, BC     +1 250 762-7675           RoboHack <[email protected]>
Planix, Inc. <[email protected]>     Avoncote Farms <[email protected]>

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCaOcXLQAKCRBmfXG3eL/0
f9YaAKCWayDI+X8t/HpUp1rF/YdgxOCGnQCg01geMx7fcBICxx8u+YogzsRoUhk=
=oCBk
-----END PGP SIGNATURE-----