Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

rustc mistakes non-rust crates for candidates #13010

Closed
auroranockert opened this issue Mar 19, 2014 · 4 comments
Closed

rustc mistakes non-rust crates for candidates #13010

auroranockert opened this issue Mar 19, 2014 · 4 comments

Comments

@auroranockert
Copy link
Contributor

I'm trying to build an application that depends on a crate called cairo.

rustc cairo.rs/examples/example1.rs -L ~/.homebrew/lib -L .

But instead of it finding the right crate, I get two unrelated libraries that it cannot disambiguate (since they are from the 'real' cairo, not my wrapper) https://gist.github.com/jensnockert/221ef976bcae3a1f13ff
@brson
Copy link
Contributor

brson commented Mar 19, 2014

rustc seems to be using a fairly imprecise heuristic for finding candidate crates. Apparently this used to work.

@brson
Copy link
Contributor

brson commented Mar 19, 2014

The problem is probably that this file name format "foo-bar-baz" is the same as our "libfoo-hash-version". rustc could first check that "hash" contains the right set of characters, but could also open the files and read the metadata before deciding they are real candidates.

@brson brson changed the title Cannot find correct crate rustc mistakes non-rust crates for candidates Mar 19, 2014
@brson brson added the I-wrong label Mar 19, 2014
@alexcrichton
Copy link
Member

Oh dear it should definitely be finding metadata before emitting any errors.

@alexcrichton alexcrichton mentioned this issue Mar 19, 2014
Closed
bors added a commit that referenced this issue Mar 20, 2014
@bors
auto merge of #13017 : alexcrichton/rust/issue-13010, r=huonw
c01e2f0 
Previously, any library of the pattern `lib<name>-<hash>-<version>.so` was
>considered a candidate (rightly so) for loading a crate. Sets are generated for
each unique `<hash>`, and then from these sets a candidate is selected. If a set
contained more than one element, then it immediately generated an error saying
that multiple copies of the same dylib were found.

This is incorrect because each candidate needs to be validated to actually
contain a rust library (valid metadata). This commit alters the logic to filter
each set of candidates for a hash to only libraries which are actually rust
libraries. This means that if multiple false positives are found with the right
name pattern, they're all ignored.

Closes #13010
@auroranockert
Copy link
Contributor Author

Thank you! I'll test it later.

lnicola pushed a commit to lnicola/rust that referenced this issue Aug 16, 2022
@bors
Auto merge of rust-lang#13010 - Veykril:build-script-probes, r=Veykril
5941dec 
Do not unconditionally succeed RUSTC_WRAPPER checks when run by build scripts

rust-analyzer's RUSTC_WRAPPER unconditionally succeeds `cargo check`
invocations tripping up build scripts using `cargo check` to probe for
successful compilations. To prevent this from happening the RUSTC_WRAPPER
now checks if it's run from a build script by looking for the
`CARGO_CFG_TARGET_ARCH` env var that cargo sets only when running build
scripts.
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 11, 2024
@bors
Auto merge of rust-lang#13010 - notriddle:notriddle/unbalanced-ticks-…
3af2005 
…backslash, r=blyxyas

doc_markdown: detect escaped `` ` `` when checking unmatched

```
changelog: [`doc_markdown`]: correctly detect backslash-escaped `` ` ``
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

rustc: Prevent false positives in crate loading alexcrichton/rust
3 participants
@auroranockert @alexcrichton @brson