Summary
iceoryx2-pal-posix-qnx8 (vendored from qorix-group/iceoryx2, MODULE.bazel:192-195, no crate_features set in the crate.annotation) always builds its socket_macros.c shim via bindgen+cc unless the crate's own libc_platform feature is enabled — which it currently isn't, for any consumer.
Where
iceoryx2-pal/posix/build.rs (in the vendored fork):
#[cfg(not(feature = "libc_platform"))]
fn main() {
...
let target_os = std::env::var("CARGO_CFG_TARGET_OS").unwrap();
if target_os.as_str() == "none" { return; }
#[cfg(not(target_os = "android"))]
if target_os != "android" {
// bindgen over posix.h, then cc::Build().file("src/c/socket_macros.c")
...
}
}This isn't QNX-specific — it runs for essentially every real target_os (Linux included) whenever libc_platform is off. The crate's own Cargo.toml doc comment on libc_platform says enabling it "simplifies cross-compilation since bindgen is not required anymore," at the cost of only supporting "a subset of the supported platforms."
Impact
Bazel's toolchain resolution is invocation-global, not scoped per bzlmod module. A consuming repo that registers its own (deliberately minimal/hermetic) C/C++ toolchain for unrelated C++ code ends up having that same toolchain used to compile this crate's socket_macros.c too — which fails if that toolchain's sysroot doesn't have full POSIX headers. Downstream symptom: eclipse-score/kyron#166 (reproduced there via communication's hermetic gcc_toolchain).
Suggested direction
For non-QNX targets (Linux at least), consider publishing/aliasing a build of iceoryx2-pal-posix-qnx8 with crate_features = ["libc_platform"] set in the crate.annotation — the libc crate is pure-Rust FFI declarations for Linux, so this should avoid the bindgen/cc build-script path (and the toolchain collision) entirely for that platform. Whether libc_platform is viable for the QNX target too (i.e. whether libc's QNX support covers everything iceoryx2-pal-posix needs) would need checking separately — the doc comment's "only a subset of platforms" caveat suggests it might not be safe to flip on unconditionally for QNX.
Not investigated here
Whether a select()-based alias (QNX gets the current bindgen/cc build, other targets get libc_platform) is feasible at the crate.annotation/BUILD-alias level in this repo's setup, or whether it needs to be a wholly separate crate.spec entry.
Summary
iceoryx2-pal-posix-qnx8(vendored fromqorix-group/iceoryx2,MODULE.bazel:192-195, nocrate_featuresset in thecrate.annotation) always builds itssocket_macros.cshim viabindgen+ccunless the crate's ownlibc_platformfeature is enabled — which it currently isn't, for any consumer.Where
iceoryx2-pal/posix/build.rs(in the vendored fork):This isn't QNX-specific — it runs for essentially every real
target_os(Linux included) wheneverlibc_platformis off. The crate's ownCargo.tomldoc comment onlibc_platformsays enabling it "simplifies cross-compilation since bindgen is not required anymore," at the cost of only supporting "a subset of the supported platforms."Impact
Bazel's toolchain resolution is invocation-global, not scoped per bzlmod module. A consuming repo that registers its own (deliberately minimal/hermetic) C/C++ toolchain for unrelated C++ code ends up having that same toolchain used to compile this crate's
socket_macros.ctoo — which fails if that toolchain's sysroot doesn't have full POSIX headers. Downstream symptom:eclipse-score/kyron#166(reproduced there viacommunication's hermeticgcc_toolchain).Suggested direction
For non-QNX targets (Linux at least), consider publishing/aliasing a build of
iceoryx2-pal-posix-qnx8withcrate_features = ["libc_platform"]set in thecrate.annotation— thelibccrate is pure-Rust FFI declarations for Linux, so this should avoid thebindgen/ccbuild-script path (and the toolchain collision) entirely for that platform. Whetherlibc_platformis viable for the QNX target too (i.e. whetherlibc's QNX support covers everythingiceoryx2-pal-posixneeds) would need checking separately — the doc comment's "only a subset of platforms" caveat suggests it might not be safe to flip on unconditionally for QNX.Not investigated here
Whether a
select()-based alias (QNX gets the current bindgen/cc build, other targets getlibc_platform) is feasible at thecrate.annotation/BUILD-alias level in this repo's setup, or whether it needs to be a wholly separatecrate.specentry.