bind9 fails to start on machines where glibc does not provide L1 cache size

Summary

There are machines where sysconf() cannot return a value for the L1 cache size, so it returns 0.

BIND version used

# named -V
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted

Based on my package manager, I believe this is bind9-9.17.22.

Steps to reproduce

Run bind9-9.17.22 on arm32.

What is the current bug behavior?

The change in 4f78f9d7 introduced a runtime assert that the compiled-in cache line size matches the runtime one.

However, on 32-bit ARM machines, glibc will not report an L1 cache line size. It appears as though sysconf() is not implemented specifically in glibc's ARM port.

It falls through to the implementation here, which returns 0.¹

Unfortunately, this all happens after (1) we check whether sysconf is available and (2) we check whether _SC_LEVEL1_DCACHE_LINESIZE is available. It is available, but wrong.

¹I don't understand why it returns 0 when the documented return value in a failure is -1. This is discussed briefly on the binutils mailing list.

What is the expected correct behavior?

named, dig, ... run.

Relevant configuration files

None - this happens in early startup regardless of config.

Relevant logs and/or screenshots

root@deneb:~# named -V
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
root@deneb:~# dig @localhost google.com
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
root@deneb:~# nslookup howett.net
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted