0.9.0

A build can state which version of this library it holds.

Two rounds of mcpplibs/openkal-linux#13 were answered against the wrong version, and the software gave no way to settle the question. The only version-shaped thing a program could read was uname's release field, which was the string literal "0.5.0" through every release after 0.5.0. That is not a missing answer but a wrong one — a consumer who checked it was misled rather than left uncertain.

$ OPENKAL_MUSL_TRACE=enosys ./your-program
openkal-musl 0.9.0
openkal-musl: no operation for system call 266

The version line is printed before the program runs and whether or not anything is missing, once per process. That last part is the substance: a run in which nothing was refused printed nothing at all, so "the version is right and nothing is absent", "the variable did not take effect" and "this is not the binary I think it is" were one reading.

uname's release field carries the same string. It is read from mcpp.toml by build.mcpp rather than written out a second time, so it cannot drift; a manifest that cannot be read yields unknown, which is a true statement.

⚠️ The release field therefore moves at every release. Nothing here or in musl reads it — gethostname and getdomainname are musl's only consumers of uname and both read nodename — but a program above that compares the field against a fixed string will see it change. Recorded in README.md's divergence table.

Nothing changes for a program that does not ask. With the variable unset the library writes zero bytes to the error stream, and that is asserted in continuous integration on every row, precisely so this cannot become noise in an ordinary run.