ci: force GNU ld on Linux to fix -ljvm linker error#4024
Merged
mbutrovich merged 2 commits intoapache:mainfrom Apr 22, 2026
Merged
ci: force GNU ld on Linux to fix -ljvm linker error#4024mbutrovich merged 2 commits intoapache:mainfrom
mbutrovich merged 2 commits intoapache:mainfrom
Conversation
Recent Rust stable defaults to rust-lld as the linker on
x86_64-unknown-linux-gnu. rust-lld cannot resolve -ljvm against the
Zulu JDK layout installed by actions/setup-java, producing:
rust-lld: error: unable to find library -ljvm
GNU ld resolves it fine. Add -Clink-arg=-fuse-ld=bfd via workflow-level
RUSTFLAGS so every cargo invocation in Linux CI picks GNU ld, and
extend the per-step RUSTFLAGS values that already set -Ctarget-cpu to
include the same flag (step-level env overrides workflow-level).
The macOS Build Native Library job fails with:
ld: warning: search path '.../Java_Zulu_jdk/17.0.18-8/aarch64/lib/server' not found
ld: library 'jvm' not found
native/fs-hdfs/build.rs resolves JAVA_HOME at build time and emits
`cargo:rustc-link-search=native=$JAVA_HOME/lib/server` plus a
`-Wl,-rpath,$JAVA_HOME/lib/server` link arg. Those paths are baked into
the compiled rlib. Because the build script does not declare any
`rerun-if-env-changed=JAVA_HOME`, Cargo has no input that lets it
detect a JDK swap, and a cache restored from a previous run (where
setup-java installed a different Zulu patch version) keeps the stale
paths.
Two changes:
- native/fs-hdfs/build.rs: add `cargo:rerun-if-env-changed=JAVA_HOME`
so Cargo reruns the build script and refreshes link args whenever
the resolved JDK changes. This is the robust fix and applies on
every host, not just CI.
- .github/workflows/pr_build_macos.yml: bump the cache key prefix to
`cargo-ci-v2` so the existing macOS cache, built against a JDK path
that no longer exists on the runner, is discarded once. After this
one-shot bust, the build.rs change handles future JDK updates on
its own.
parthchandra
approved these changes
Apr 21, 2026
Contributor
parthchandra
left a comment
parthchandra
left a comment
There was a problem hiding this comment.
approved. pending ci
comphead
approved these changes
Apr 21, 2026
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
4 participants
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.
Which issue does this PR close?
Closes #.
Rationale for this change
Linux CI has been failing on main since ~2026-04-21 20:55 UTC on every
PR with:
The failure reproduces on main at
cae101e80and every later commit,across
PR Build (Linux),Spark SQL Tests, andIceberg Spark SQL Testsworkflows. None of the commits in that window touch native codeor build scripts, so the regression came from the environment.
Rust's
stablechannel (used by the workflows) released a versionduring that window that defaults to
rust-lldas the linker onx86_64-unknown-linux-gnu. The failing linker command clearly shows-fuse-ld=lld.rust-lldcannot resolve-ljvmagainst the ZuluJDK 17 layout that
actions/setup-java@v4installs under/__t/Java_Zulu_jdk/17.0.18-8/x64/lib/server/— GNUld.bfdresolvesit fine.
What changes are included in this PR?
Adds
-Clink-arg=-fuse-ld=bfdtoRUSTFLAGSin the three Linux CIworkflows:
pr_build_linux.yml,spark_sql_test.yml, andiceberg_spark_test.yml.env:so every cargo invocation (includingthose inside the composite
rust-testaction, which has no explicitRUSTFLAGS) picks up GNU ld.
RUSTFLAGS: "-Ctarget-cpu=x86-64-v3"values to include the same flag, because step-level env replaces
workflow-level env rather than appending.
macOS CI is also failing but with a different root cause
(
ld: library 'jvm' not found, path to Zulu does not exist on therunner). That is a separate issue and is not addressed here.
How are these changes tested?
By running the affected workflows on this PR. If the Linux
Build Native Library,ubuntu-latest/rust-test,Spark SQL Tests, andIceberg Spark SQL Testsjobs all reach a normal pass/fail stateinstead of failing at the linker, the fix is confirmed.