0.9.1

Carries openkal-linux 0.12.0, which fixes a defect every consumer of this
package is exposed to: a program that needs an interpreter — a #! script
on any architecture, or a binary of another architecture through binfmt_misc —
could not be started at all.

0.9.0

Follows openkal-musl 0.13.0.

0.13.0 fixes a defect consumers of this package are exposed to: kill(-n) aimed
at a unit the caller could not name reached the caller's OWN unit, so an enquiry
about a unit that did not exist was answered yes and a signal aimed at one
ended the caller together with everything it led.

0.8.0

What's Changed

• 0.8.0 --- follow openkal 0.11 by @Sunrisepeak in #14

Full Changelog: 0.7.0...0.8.0

0.7.0

What's Changed

• 0.7.0 — repin the C library, whose locks now exclude and whose kill now reaches by @Sunrisepeak in #13

Full Changelog: 0.6.0...0.7.0

0.6.0 — repin the C library, whose exec search a consumer could not reach

openkal-musl 0.10.0
— the exec search, and the family of answers that were not true (openkal-linux#13).

⚠️⚠️ This repin is not a formality

A version requirement is exact here and nothing floats up, so this package's
pin is the whole of what a C++ consumer can have. Without this release a program
that writes both lines does not get the new C library — and does not get the old
one either:

error: dependency 'mcpplibs.openkal-musl' has irreconcilable versions:
  '0.10.0' requested by '<the program>'
  '0.9.0'  requested by 'mcpplibs.openkal-llvm-runtime@0.5.0'

⇒ A C++ program writes one line:

[dependencies]
openkal-llvm-runtime = "0.6.0"   # carries openkal-musl 0.10.0

Verified through this package rather than beneath it

The reporter's own case — a lock directory's timestamp, both overloads,
through libc++:

reading a lock directory's mtime (never was broken)      ok
refreshing it -- the overload that actually failed       ok
and the value read back is the one just written          ok

Reading was never broken. Refreshing was, and was reported as a read failure
because libc++ gives both overloads one name in the message it throws.

0.5.0

Repins the C library to openkal-musl 0.9.0, which answers truncate(2), repins openkal-linux 0.7.1 and openkal-macos 0.6.1, and makes a build able to state which version of the C library it holds.

What a program above this package gets

Two things that did not work now do, and neither is a C++ problem — both are std::filesystem reaching a system call.

std::filesystem::copy_file reported Resource temporarily unavailable for two ordinary files. libc++ opens a copy's source with O_RDONLY | O_NONBLOCK | O_BINARY, which on a kernel is meaningless for a regular file and is ignored. openkal-musl routes an O_NONBLOCK descriptor through the bounded-transfer path and expresses copy_file_range as a read/write loop, so every byte of a file copy went through it — and the backends' kal_timeout_read decoded a borrowed kal_stream handle with the decoder for an owned one, waiting upon the descriptor below the one it then transferred upon. EAGAIN is not in libc++'s fallback list, so the error reached the caller verbatim.

std::filesystem::resize_file worked for no path at all, because libc++ expresses it as the name-shaped truncate and only the descriptor-shaped ftruncate was answered.

Both reported in mcpplibs/openkal-linux#13.

A consumer can now say what it built

$ OPENKAL_MUSL_TRACE=enosys ./your-program
openkal-musl 0.9.0

Named before the program runs and whether or not anything is missing. Two rounds of that issue were answered against the wrong version because neither this line nor an honest uname release field existed. With the variable unset the library writes zero bytes to the error stream, asserted on every row of its matrix.

Verified through the index rather than through working trees

Every repository in this family substitutes working trees for its dependencies in CI, so none of those runs examines the index entry, the archive, its hash or the resolved graph. One program, one source file, differing only in the version its manifest names:

openkal-musl = "0.7.0"      (index+mcpplibs@0.7.0 -> openkal-linux 0.7.0)
  note: 1 of 16 pipes reported readable
  FAIL: a pipe with a byte in it is reported readable

openkal-musl = "0.8.0"      (index+mcpplibs@0.7.1 -> openkal-linux 0.7.1)
  ok: truncate(2) by name
  ok: the length set by name is reported
  ok: a pipe with a byte in it is reported readable

Sixteen pipes, a byte written into each, poll(POLLIN) on each reading end. One of sixteen passed under the defect — the first, the only one whose neighbour below was not the previous pipe's writing end.

0.4.0

openkal-llvm-runtime 0.4.0 — repin on openkal-musl 0.7.0

No change to what this package builds. It follows openkal-musl to 0.7.0, which
follows openkal to 0.9.0.

One test changed, and it changed because a limitation was lifted.
examples/cxx asserted that creating a symbolic link is refused. openkal 0.9
added the operation, openkal-musl 0.7 answers symlinkat with it, and the
refusal stopped arriving — so the assertion failed, which is the good case. The
link is now created, read back, and asked about both ways: an enquiry that does
not resolve reports the link, one that resolves reports the file.

This repository's bare-metal row is where two defects one package away were
found: an optional openkal operation reached without the weak-reference seam
(a link failure on the only configuration that has no filesystem), and a C
library page size taken from a granularity of one.