Conversation
Root cause: the file-path branch of parse_libs_cflags emits a bare `rustc-link-lib=`, discarding the suffix that extract_lib_from_filename already matched. When a shared library of the same base name sits in the same directory, the linker picks it, so `Libs.private: /path/libfoo.a` under statik(true) silently produces a dynamically linked binary. Emit `static=` when the file name ends in `.a`. A Windows `.lib` can be an import library, so the extension decides nothing there. No fixture named a library by file path before this, so the branch behind issue rust-lang#134 had no coverage.
AlJohri
marked this pull request as ready for review
September 30, 2026 20:18
This branch has not been deployed
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.
When a
.pcnames a library by file path, the emittedcargo:rustc-link-lib=drops the suffix
extract_lib_from_filenamealready matched. If a.soof thesame base name sits in that directory, the linker picks it — silently, under
statik(true).conda-forge's
rdkafka-static.pc:librdkafka.aandlibrdkafka.so.1are both in${libdir}. On 0.3.34,Config::new().statik(true).probe("rdkafka-static")emitscargo:rustc-link-lib=rdkafka, and the binary comes out linked againstlibrdkafka.so.1.Library.link_fileshas the archive path; only the emissionloses it.
Fix: emit
static=when the name ends in.a. A Windows.libcan be animport library, so Windows is unchanged.
Not gated on
statik— a path tolibfoo.astates the kind on its own, andthis is not confined to
Libs.private: the vcpkg Qt5 example in #134 names ninearchives in plain
Libs:. Happy to gate it if you'd rather.Tests: there was no fixture naming a library by file path, so #134's branch
had no coverage. Adds one, plus two unit tests. They assert on
Library, not onthe emitted metadata — that goes to
println!and nothing captures it, so thechanged line is still untested.
cargo fmt --checkclean, existing suiteunchanged. Not built against MSRV 1.63 locally.
Follow-up:
verbatim#134 found the right mechanism and stopped because it was unstable. It
stabilized in 1.67 (rust-lang/rust#104360).
static:+verbatim=libfoo.alinks thenamed file, so the ambiguity can't arise. Written and verified against the same
case: AlJohri/pkg-config-rs@static-link-archive-named-by-path...static-link-archive-verbatim
One expression, plus an MSRV bump to 1.67 — which is why it isn't in this PR.
Say the word and I'll swap it in.
Related
-lpath, doesn't reach here