test(ffi): build the cdylib in c_smoke instead of linking a stale one

The C smoke test linked whatever libsandlock_ffi.so already existed in
target/, but Cargo does not treat the cdylib as a build prerequisite of an
integration test (tests link the rlib). So `cargo test` never (re)builds
the .so, and CI linked a stale artifact missing newer symbols
(undefined reference to sandlock_action_set_inject_bytes).

Build the cdylib from within the test via `cargo build -p sandlock-ffi
--lib` before locating and linking it, so the C test always links the
current artifact. The recursive cargo invocation is safe — the outer build
lock is released before tests run. Verified by deleting the .so and
re-running: the test rebuilds it and passes.

Signed-off-by: Cong Wang <cwang@multikernel.io>

Author: congwang-mk

crates/sandlock-ffi/tests/c_smoke.rs

@@ -12,6 +12,22 @@ fn c_smoke_compiles_and_runs() {
     } else {
         "release"
     };
+
+    // Cargo links integration tests against the crate's *rlib*, and does not
+    // treat the *cdylib* as a build prerequisite — so `cargo test` never
+    // (re)builds `libsandlock_ffi.so`. Build it ourselves so we always link the
+    // current artifact instead of a stale one left in `target/` (which fails
+    // with "undefined reference" when the symbol set has changed). `--lib`
+    // builds the cdylib/staticlib/rlib; the recursive `cargo` is safe because
+    // the outer build lock is released before tests run.
+    let mut build = Command::new(env!("CARGO"));
+    build.args(["build", "-p", "sandlock-ffi", "--lib"]);
+    if profile == "release" {
+        build.arg("--release");
+    }
+    let build_status = build.status().expect("invoke cargo build for cdylib");
+    assert!(build_status.success(), "failed to build sandlock-ffi cdylib");
+
     let target_dir = std::env::var_os("CARGO_TARGET_DIR")
         .map(PathBuf::from)
         .unwrap_or_else(|| {