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

On Tue, 7 Oct 2025, Greg A. Woods wrote:

> Those beNNXXc() functions should be inlined, I think -- they are defined
> in <sys/endian.h> via a set of macros for any compiler since gcc-2.95.
>

Those beNNXXc() functions are tested twice, actually. First, during the
creation of `nbtool_config.h' by `tools/compat/configure'. The second, when
sha2.c is compiled.

Only in the first case is <sys/endian.h> used, and here, the beNNXXc() are
not seen and `tools/include/compat/nbtool_config.h' ends up with:

```
#define HAVE_DECL_BE64DEC 0
#define HAVE_DECL_BE64ENC 0
```

etc., because `configure' compiles the test progs. as follows:

```
configure: failed program was:
| /* confdefs.h */
[...]
| #define _POSIX_SOURCE 1
| #define _POSIX_C_SOURCE 200112L
| #define _XOPEN_SOURCE 600
[...]
| /* end confdefs.h.  */
| #include <sys/endian.h>
|
| int
| main ()
| {
| #ifndef be64enc
| #ifdef __cplusplus
|   (void) be64enc;
| #else
|   (void) be64enc;
| #endif
| #endif
|
|   ;
|   return 0;
| }
configure:5981: result: no
```

Defining `_POSIX_SOURCE 1' undefs `_NETBSD_SOURCE' in <sys/featuretest.h>

When compiling sha2.c, <sys/endian.h> isn't used at all. What's used are the
beNNXXc() definitions in `tools/compat/compat_defs.h':

sha2.c -> nbtool_compat.h -> compat_def.h -> beNNXXc()

because `nbtool_compat.h' gets pulled in, and now has (as expected):

```
/* Define to 1 if you have the declaration of `be64dec', and to 0 if you
    don't. */
#define HAVE_DECL_BE64DEC 0

/* Define to 1 if you have the declaration of `be64enc', and to 0 if you
    don't. */
#define HAVE_DECL_BE64ENC 0
```

as a result of the `./configure' tests.

> However they do not get inlined:
>
> $ nm /home/sysbuild/i386/obj/home/sysbuild/src/tools/compat/sha2.lo
> 00000340 r K256
> 00000080 r K512
> 000002d5 t SHA224_256_Final
> 00000914 T SHA224_Final
> 00000834 T SHA224_Init
> 000008f8 T SHA224_Transform
> 000008d5 T SHA224_Update
> 0000081f T SHA256_Final
> 00000000 T SHA256_Init
> 000000a1 T SHA256_Transform
> 0000056e T SHA256_Update
> 000017ef T SHA384_Final
> 000016bd T SHA384_Init
> 000017d3 T SHA384_Transform
> 000017b0 T SHA384_Update
> 00001630 T SHA512_Final
> 00000929 T SHA512_Init
> 00000fec t SHA512_Last
> 00000a1c T SHA512_Transform
> 000012ad T SHA512_Update
>         U be32dec
>         U be32enc
>         U be64dec
>         U be64enc
> 00000320 r sha224_initial_hash_value
> 00000300 r sha256_initial_hash_value
> 00000040 r sha384_initial_hash_value
> 00000000 r sha512_initial_hash_value
>

They should get inlined. Well, at least some of them should: the compiler can
inline the code depending on optimization flags and code usage, it looks like:

```
qemu$ nm /tmp/obj/home/rvp/src/netbsd-10/tools/compat/sha2.lo
0000000000000340 r K256
0000000000000080 r K512
00000000000002f5 t SHA224_256_Final
0000000000000922 T SHA224_Final
0000000000000839 T SHA224_Init
0000000000000917 T SHA224_Transform
000000000000090c T SHA224_Update
0000000000000829 T SHA256_Final
0000000000000007 T SHA256_Init
00000000000000da T SHA256_Transform
0000000000000603 T SHA256_Update
0000000000001304 T SHA384_Final
000000000000121e T SHA384_Init
00000000000012f9 T SHA384_Transform
00000000000012ee T SHA384_Update
0000000000001180 T SHA512_Final
0000000000000932 T SHA512_Init
0000000000000c44 t SHA512_Last
0000000000000a02 T SHA512_Transform
0000000000000eb5 T SHA512_Update
0000000000000000 t be64enc			<---
                  U memcpy
0000000000000320 r sha224_initial_hash_value
0000000000000300 r sha256_initial_hash_value
0000000000000040 r sha384_initial_hash_value
0000000000000000 r sha512_initial_hash_value
qemu$
```

Note that on amd64, only `be64enc' is visible because only that func. is used
twice in the code. All of the others are used only once, so, presumably, the
compiler has inlined the code of those funcs. rather than inlining those
functions themselves.

So, this looks like some local issue. Does `nbtool_config.h' have

```
#define HAVE_DECL_BE64DEC 1
```

or something?

HTH,

-RVP