Libraries

Why it matters

A small unsupported dependency can block an otherwise successful application port, so library status should be checked early.

In brief

Libraries are where application ports meet existing binary interfaces, allocation, callbacks, assembly and data-layout assumptions. A useful CHERI library catalogue records architecture, ABI, version, test status and any remaining capability-related limitations.

For each library, record whether it merely compiles, passes its normal test suite, runs under a pure-capability ABI and is maintained upstream. These are different levels of readiness. Prioritise libraries on the critical path of a representative application instead of porting by popularity alone.

Key considerations

1. Inventory

List direct and transitive libraries, generated bindings, plugins and runtime-loaded components.

2. Assess

Check pure-capability or hybrid build status, tests, pointer-size assumptions, assembly and ownership of allocations.

3. Maintain

Upstream fixes where possible and record patches, licences, versions and responsible maintainers.

Evidence and caveats

A library that compiles may still have insufficient tests, over-broad bounds or unsafe interface assumptions. Treat build status and security review separately.

Treat build, test, integration, upstream and maintained support as distinct states. Name the target and last verified date.

Primary routes

• CheriBSD packages and project