register openkal-musl 0.19.2 - #467

0.19.2 ships the eight archives musl's own `make install` places beside
libc.a (libm, librt, libpthread, libcrypt, libutil, libxnet, libresolv and
libdl, each empty) and names their directory in its Linux ldflags. A program
over this runtime that writes `-lm` is then answered by the graph's C library.
From mcpp 2026.9.26.1 a link over a graph-supplied C library searches no host
library directory (mcpp-community/mcpp#696), and without the archives such a
`-lm` is unanswered; before it, the host's glibc archive answered it.

0.19.2 was registered and published before this pin moved
(mcpplibs/mcpp-index#467, index artifact 1529f5f). No source changed.

Co-authored-by: speak-agent <[email protected]>

Registration only: nothing here pins it yet; tests/openkal/pins.toml moves
with the mcpp release that needs it.

0.15.2 pins openkal-musl 0.19.2 (registered in #467), which ships the eight
empty archives musl installs beside libc.a. The runtime pins openkal-musl
exactly, so this is the version a consumer moves to receive them: a root that
pins openkal-musl 0.19.2 beside runtime 0.15.1 is refused as irreconcilable
(measured). From mcpp 2026.9.26.1 a link over a graph-supplied C library
searches no host library directory (mcpp-community/mcpp#696), and `-lm` is
answered by those archives or by nothing.

Both urls were fetched before this entry was written: each serves 15631743
bytes with sha256 c2219ad8...c0d0d9, and the CN copy is byte-for-byte
identical to the GitHub archive. The archive's mcpp.toml reads version 0.15.2
and openkal-musl = "0.19.2".

Co-authored-by: speak-agent <[email protected]>

…rgets in the openkal measurement (#469)

Pins move, with no registration in this change (openkal-musl 0.19.2 and
openkal-llvm-runtime 0.15.2 were registered in #467 and #468 and resolved from
the published index before anything here named them):

- validate.yml and openkal-compat.yml install mcpp 2026.9.26.1, and
  index.toml's latest_mcpp names it. min_mcpp does not move: the release
  changes no descriptor grammar.
- tests/openkal/pins.toml: runtime 0.15.2 (which pins openkal-musl 0.19.2
  exactly), mcpp 2026.9.26.1, and two targets, x86_64-linux-musl and
  aarch64-linux-musl. From mcpp 2026.9.26.1 a link over the graph's C library
  searches no host library directory (mcpp-community/mcpp#696); before it, a
  member's `-lm` on x86_64-linux-musl linked the host's glibc objects without
  a diagnostic. Neither target was measured here, which is why neither showed.
- compat.py: a Linux image of the host's own architecture runs without a
  runner (`host_executes`), so x86_64-linux-musl is measured as run rather
  than `--no-run`; aarch64-linux-musl runs under qemu-aarch64, which the
  workflow now installs. Three selftest cases state the rule.
- compat.libaio, compat.libdrm and compat.libinput: the comments that blamed
  `c_standard = "gnu11"` itself now name the defect (a dependency's own C
  standard was dropped up to mcpp 2026.9.25.1, mcpp-community/mcpp#695) and
  keep the `-D` spellings, which work under every engine this index admits.

Co-authored-by: speak-agent <[email protected]>