bug(rvf-runtime): macOS link failure — hard-coded glibc __errno_location in locking.rs

[aepod]

Summary

rvf-runtime declares a glibc-only extern "C" fn __errno_location() in locking.rs under #[cfg(unix)]. On macOS (and other non-glibc Unix), the libc errno accessor is __error, not __errno_location, so any binary/test that links rvf-runtime fails with an undefined symbol.

cargo check / rlib builds succeed; failure appears only at final link of an executable.

Affected versions

• Confirmed: 0.2.0 (src/locking.rs ~277–294)
• Confirmed still present: 0.3.0 (locking.rs ~304 / ~324)
• crates.io max at report time: 0.3.2 (please re-check)

Repro (macOS)

# Cargo.toml
[dependencies]
rvf-runtime = { version = "0.2", default-features = false, features = ["std"] }
tempfile = "3"

use rvf_runtime::{DistanceMetric, RvfOptions, RvfStore};

fn main() {
    let dir = tempfile::tempdir().unwrap();
    let path = dir.path().join("t.rvf");
    let opts = RvfOptions {
        dimension: 4,
        metric: DistanceMetric::L2,
        ..Default::default()
    };
    let _ = RvfStore::create(&path, opts).expect("create");
    let _ = RvfStore::open(&path).expect("open");
}

cargo build
# ld: Undefined symbols: ___errno_location

Expected

Portable errno access via the libc crate or per-OS cfg (__error on macOS/BSD, __errno_location on Linux).

Suggested fix

fn libc_errno() -> *mut i32 {
    // libc crate provides a portable surface
    unsafe { libc::__errno_location() }
}

or:

#[cfg(target_os = "linux")]
extern "C" { fn __errno_location() -> *mut i32; }
#[cfg(any(target_os = "macos", target_os = "ios", target_os = "freebsd"))]
extern "C" { fn __error() -> *mut i32; }

Downstream impact

WeftOS / clawft (clawft-cow-memory) ships a #[no_mangle] shim that exports __errno_location → libc::__error() so macOS CI and local tests can link. That is a fragile single-definition symbol (fat-LTO multiplies duplicates). An upstream fix lets all consumers drop the shim.

Reported from WeftOS ticket WEFT-662. Full write-up with two sibling bugs:
https://github.com/ (local doc: docs/research/rvf-runtime-0.2-upstream-bugs.md in weftos).

[ohdearquant]

Answering the "crates.io max at report time: 0.3.2 (please re-check)" line: 0.3.2 already has the fix.

I checked the published source rather than the version number, by downloading the crate from the
registry and reading what shipped:

$ curl -L -o rvf.crate https://crates.io/api/v1/crates/rvf-runtime/0.3.2/download
$ tar xzf rvf.crate && grep -n -B2 '__errno_location\|__error()' rvf-runtime-0.3.2/src/locking.rs
302-#[cfg(any(target_os = "linux", target_os = "android"))]
303-extern "C" {
304:    fn __errno_location() -> *mut i32;
307-#[cfg(any(target_os = "macos", target_os = "ios", target_os = "freebsd"))]
308-extern "C" {
309:    fn __error() -> *mut i32;

0.3.2 was published 2026-07-28, two days before this issue was filed, so the repro against 0.2 and
0.3.0 was accurate at the time and a cargo update resolves it. macOS links __error and the
undefined-symbol failure is gone.

One thing worth keeping open, and I've sent it as #757 rather than reopening this one, because it is
a different defect: the fix covers linux, android, macos, ios and freebsd, while the caller
is_pid_alive is compiled under #[cfg(unix)]. Those are different sets. On the Unix targets in the
gap the caller now exists without its callee, which turns the original link failure into a compile
failure:

$ cargo check -p rvf-runtime --target x86_64-unknown-netbsd
error[E0425]: cannot find function `libc_errno` in this scope
   --> crates/rvf/rvf-runtime/src/locking.rs:283:29

crates/rvlite/src/storage/writer_lease.rs carries the same shape behind --features rvf-backend.
#757 replaces the hand-declared symbols with std::io::Error::last_os_error(), which reads errno
through each platform's own accessor and so covers all of unix without maintaining a per-OS list.

[ruvnet]

Fixed on main. locking.rs now cfg-gates the errno accessor per platform: __errno_location() under target_os = "linux"/"android" (:302-305) and __error() under macos"/"ios"/"freebsd" (:307-310), with matching libc_errno() implementations at :322 and :328.

Verified by linking an actual executable on macOS (arm64, Darwin 25.1): cargo build -p rvf-cli succeeds with no undefined symbols — which is the case the issue notes cargo check would miss.

Closing as resolved; reopen if it still reproduces on another non-glibc target (the cfg list doesn't cover e.g. netbsd/openbsd, which would fall through to no libc_errno at all).

🤖 Generated with claude-flow