viyatb-oai 9766d3d51c fix(bwrap): emit libcap after standalone archive (#21285) ...

## Why

#21255 added the standalone `codex-bwrap` binary. In the Cargo build,
[`pkg_config::probe("libcap")`](https://github.com/openai/codex/blob/a736cb55a2bce57b4c8e5a4fe56f70c2b2ad892b/codex-rs/bwrap/build.rs#L37-L39)
emits `-lcap` before
[`cc::Build::compile("standalone_bwrap")`](https://github.com/openai/codex/blob/a736cb55a2bce57b4c8e5a4fe56f70c2b2ad892b/codex-rs/bwrap/build.rs#L50-L67)
adds the static bwrap archive. The Linux musl link then sees `-lcap
-lstandalone_bwrap`; because static archives are resolved left-to-right,
`cap_from_name` is still undefined once `standalone_bwrap` introduces
that reference.

The musl setup already builds `libcap.a` and exposes it through
[`libcap.pc`](https://github.com/openai/codex/blob/a736cb55a2bce57b4c8e5a4fe56f70c2b2ad892b/.github/scripts/install-musl-build-tools.sh#L78-L88),
so the failure is link ordering rather than a missing dependency.

## What changed

- probe `libcap` with `cargo_metadata(false)` so `pkg-config` does not
emit its link flags early
- emit the discovered `libcap` search paths and libraries after
`standalone_bwrap` is compiled, preserving the needed static-link order

## Verification

- `cargo test -p codex-bwrap`
- `cargo clippy -p codex-bwrap --all-targets`

The affected Linux musl release link is exercised by CI, which is the
path this fix targets.

9766d3d51c · 2026-05-05 22:22:01 -07:00

History

..

src

linux-sandbox: use standalone bundled bwrap (#21255)

2026-05-05 17:14:29 -07:00

BUILD.bazel

linux-sandbox: use standalone bundled bwrap (#21255)

2026-05-05 17:14:29 -07:00

build.rs

fix(bwrap): emit libcap after standalone archive (#21285)

2026-05-05 22:22:01 -07:00

Cargo.toml

linux-sandbox: use standalone bundled bwrap (#21255)

2026-05-05 17:14:29 -07:00

config.h

linux-sandbox: use standalone bundled bwrap (#21255)

2026-05-05 17:14:29 -07:00