fix(iceoryx2): enable libc_platform for iceoryx2-pal-posix-qnx8 - #73
Open
hskang-amelia wants to merge 1 commit into
Open
Conversation
The -qnx8 variant unconditionally built a C shim (socket_macros.c via
bindgen+cc) in its build.rs for every non-QNX target too, since the
libc_platform Cargo feature (which switches the crate to a pure-Rust
implementation) was never enabled. On a consumer with its own minimal/
hermetic C++ toolchain (no libc headers registered), that shim fails to
compile with undeclared-symbol errors (size_t, fd_set, CMSG_*), colliding
with the consumer's toolchain rather than anything QNX-specific.
libc_platform is gated behind an optional `libc = { workspace = true }`
dependency in the vendored crate's Cargo.toml; since we pull it in via a
git crate with strip_prefix (no workspace root Cargo.toml present),
cargo-bazel can't resolve that version reference on its own, so the
feature alone isn't enough — wire the already-resolved libc 0.2.186 in
directly via the annotation's `deps`.
Fixes eclipse-score/kyron#166, eclipse-score#72.
|
The created documentation from the pull request is available at: docu-html |
This was referenced Sep 2, 2026
hskang-amelia
pushed a commit
to hskang-amelia/score-crates
that referenced
this pull request
Sep 8, 2026
Found the actual verified fix already exists upstream: eclipse-score#73 (open, unmerged) did exactly this and confirmed it with a real bazel build (communication as root module, per state_management's docs/design-notes.md note on it) — fetched its diff directly (git fetch origin pull/73/head) rather than re-deriving it, since a bazel-build-verified fix beats an unverified guess. The previous commit here only added crate_features = ["libc_platform"], which is not enough on its own: iceoryx2-pal-posix-qnx8's optional libc dep is declared as `{ workspace = true, optional = true }`, but the crate is pulled in via git with strip_prefix (no workspace root Cargo.toml present in that stripped view) — cargo-bazel can't resolve that version reference and silently drops the dep even with the feature on. Wiring @crate_index__libc-0.2.186//:libc in directly via `deps` (exactly matching eclipse-score#73's diff) is what actually fixes it. Still not verified end to end in this fork specifically (same Bazel unavailability as the previous commit) — same repin caveat applies. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015DfkxHTUNKeDks7ZGiKNoJ
hskang-amelia
added a commit
to hskang-amelia/score-crates
that referenced
this pull request
Sep 8, 2026
… build) (#1) * Enable libc_platform for iceoryx2-pal-posix-qnx8 (fixes Linux build) Root-caused why kyron's libkyron_foundation/liblogging_tracing fail to build on Linux even though nothing about them is QNX-specific at the Bazel level (their deps on the qorix-group iceoryx2 fork's *-qnx8 crates are unconditional, not select()-gated on QNX — there is no separate Linux-native iceoryx2 vendored here, so this fork has to build on Linux too, not just QNX). Traced it to iceoryx2-pal-posix-qnx8 specifically: its own Cargo.toml declares a `libc_platform` feature ("Use the libc crate for platform abstraction... simplifies cross-compilation since bindgen is not required anymore"), gating an optional `libc` dependency. Without it (the current state — confirmed in Cargo.Bazel.lock: no libc dep, only bindgen+cc in build_script_attrs), this crate's build.rs takes its default path: bindgen against a real C toolchain/sysroot, whose only non-generic branch handles `target_os == "nto"` (QNX) — nothing here makes that path work under a hermetic Linux Bazel toolchain. Fix: add `crate_features = ["libc_platform"]` to this crate's crate.annotation, activating the already-declared optional `libc` dep and skipping bindgen/cc entirely. IMPORTANT — not verified end to end: no Bazel toolchain was available in the environment this was written in (releases.bazel.build is blocked by network policy there), so this is a source-level fix only. Cargo.Bazel.lock was deliberately NOT hand-edited (a ~22k-line generated file — hand-editing it risks a subtly-wrong, unverifiable result far worse than leaving it stale) and still reflects the old resolution (no libc dep for this crate). Whoever picks this up needs to run `CARGO_BAZEL_REPIN=1 bazel build //...` (or this rules_rust fork's equivalent repin invocation) once, with real network access to github.com/qorix-group/iceoryx2, to regenerate it — until then, Bazel should fail loudly with a lockfile-out-of-date error rather than silently using stale data, which is the safe failure mode for this commit as it stands. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015DfkxHTUNKeDks7ZGiKNoJ * Add explicit libc dep — libc_platform feature alone silently drops it Found the actual verified fix already exists upstream: eclipse-score#73 (open, unmerged) did exactly this and confirmed it with a real bazel build (communication as root module, per state_management's docs/design-notes.md note on it) — fetched its diff directly (git fetch origin pull/73/head) rather than re-deriving it, since a bazel-build-verified fix beats an unverified guess. The previous commit here only added crate_features = ["libc_platform"], which is not enough on its own: iceoryx2-pal-posix-qnx8's optional libc dep is declared as `{ workspace = true, optional = true }`, but the crate is pulled in via git with strip_prefix (no workspace root Cargo.toml present in that stripped view) — cargo-bazel can't resolve that version reference and silently drops the dep even with the feature on. Wiring @crate_index__libc-0.2.186//:libc in directly via `deps` (exactly matching eclipse-score#73's diff) is what actually fixes it. Still not verified end to end in this fork specifically (same Bazel unavailability as the previous commit) — same repin caveat applies. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015DfkxHTUNKeDks7ZGiKNoJ --------- Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
-qnx8variant oficeoryx2-pal-posixunconditionally builds a C shim (socket_macros.c, compiled viabindgen+ccinbuild.rs) for every non-QNX target too, since thelibc_platformCargo feature (which switches the crate to a pure-Rust implementation) was never enabled here. On a consumer with its own minimal/hermetic C++ toolchain registered (no libc headers wired in), that shim fails to compile with undeclared-symbol errors (size_t,fd_set,CMSG_SPACE/CMSG_FIRSTHDR/etc.) — a toolchain collision, not anything QNX-specific. See eclipse-score/kyron#166 and #72 for the original report/analysis.Two changes were both needed (verified empirically, not just from reading source):
crate_features = ["libc_platform"]on theiceoryx2-pal-posix-qnx8annotation — this removes the C-shimbuild.rsstep entirely.deps = ["@crate_index__libc-0.2.186//:libc"]on the same annotation.libc_platformis gated behind an optionallibc = { workspace = true }dependency in the vendored crate's ownCargo.toml; since it's pulled in via a git crate withstrip_prefix(no workspace rootCargo.tomlpresent in the vendored tree),cargo-bazelcan't resolve that version reference on its own, so enabling the feature alone still fails withunresolved import 'libc'. Thelibccrate is already present in this repo's lockfile at 0.2.186 (pulled in transitively elsewhere), so this just wires it in directly.Verification
Reproduced the original failure and confirmed the fix using
eclipse-score/communicationas the Bazel root module (its own registered hermetic C++ toolchain is what originally triggers the collision — matching the root cause described in kyron#166), withscore_kyronandscore_cratesoverridden to local checkouts:bazel build @score_kyron//src/kyron-foundation:libkyron_foundationfails compilingsocket_macros.cwith the undeclared-symbol errors described above.crate_featuresonly: shim disappears, but fails witherror[E0432]: unresolved import 'libc'.depstoo: builds clean. Also verified@score_kyron//src/kyron:libkyronand@score_kyron//src/logging_tracing:liblogging_tracing(both also depend on the qnx8 iceoryx2 crates) build clean.Test plan
bazel build @score_kyron//src/kyron-foundation:libkyron_foundation(viacommunicationas root module) — passesbazel build @score_kyron//src/kyron:libkyron @score_kyron//src/logging_tracing:liblogging_tracing— passesFixes eclipse-score/kyron#166, #72.