iceoryx2-pal-posix-qnx8 always needs a C toolchain (bindgen+cc), breaking consumption from repos with their own hermetic C++ toolchain #72

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.