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.

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

Crate paths specified with --extern cause bogus duplicate crates when using symlinks #16496

Closed
dotdash opened this issue Aug 14, 2014 · 0 comments · Fixed by #16505
Closed

Crate paths specified with --extern cause bogus duplicate crates when using symlinks #16496

dotdash opened this issue Aug 14, 2014 · 0 comments · Fixed by #16505

Comments

@dotdash
Copy link
Contributor

dotdash commented Aug 14, 2014

Build servo in a path that has a symlink in it currently fails, because the url crate is used in http as well as servo's net. Both are build with the crate for url specified using --extern, but the assigned paths end up differently:

DEBUG:rustc::metadata::creader:   name: url
DEBUG:rustc::metadata::creader:   cnum: 35
DEBUG:rustc::metadata::creader:   hash: 9b74b61cf9c6fb6a
DEBUG:rustc::metadata::creader:    rlib: /home/doener/src/servo/build/x86_64-unknown-linux-gnu/src/support/url/rust-url/liburl.rlib

DEBUG:rustc::metadata::creader:   name: url
DEBUG:rustc::metadata::creader:   cnum: 20
DEBUG:rustc::metadata::creader:   hash: 9b74b61cf9c6fb6a
DEBUG:rustc::metadata::creader:    rlib: /home/doener/storage/builds/servo/x86_64-unknown-linux-gnu/src/support/url/rust-url/liburl.rlib

One path has the symlink (the build dir in this case) resolved, the other doesn't. Looks like there's a call to realpath() missing from existing_match().

Unless somebody beats me to it, I'll create a PR later today or tomorrow.

dotdash added a commit to dotdash/rust that referenced this issue Aug 15, 2014
Crates that are resolved normally have their path canonicalized and all
symlinks resolved. This does currently not happen for paths specified
using the --extern option to rustc, which can lead to rustc thinking
that it encountered two different versions of a crate, when it's
actually the same version found through different paths.

To fix this, we must store the canonical path for crates found via
--extern and also use the canonical path when comparing paths.

Fixes rust-lang#16496
bors added a commit that referenced this issue Aug 16, 2014
Crates that are resolved normally have their path canonicalized and all
symlinks resolved. This does currently not happen for paths specified
using the --extern option to rustc, which can lead to rustc thinking
that it encountered two different versions of a crate, when it's
actually the same version found through different paths.

Fixes #16496
SimonSapin added a commit to SimonSapin/servo that referenced this issue Sep 22, 2014
Currently, `mach build-cef` uses a completely separate target directory
than `mach build`, so everything gets built twice.

Now that we’ve upgraded Rust to a version that fixes
rust-lang/rust#16496,
we can make this symlink to share target directories.

"git" dependencies builds are shared as expected, but "path" dependecies
still get rebuilt for some reason that might be related to
rust-lang/cargo#497

@alexcrichton says this is unsupported behavior and we shouldn’t do it,
but it still is strictly better than what we have now as far as I can tell.
SimonSapin added a commit to SimonSapin/servo that referenced this issue Sep 22, 2014
Currently, `mach build-cef` uses a completely separate target directory
than `mach build`, so everything gets built twice.

Now that we’ve upgraded Rust to a version that fixes
rust-lang/rust#16496,
we can make this symlink to share target directories.

"git" dependencies builds are shared as expected, but "path" dependecies
still get rebuilt for some reason that might be related to
rust-lang/cargo#497

@alexcrichton says this is unsupported behavior and we shouldn’t do it,
but it still is strictly better than what we have now as far as I can tell.
matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this issue Feb 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant