Installing multiple versions doesn't work well #3225
Comments
|
This is by design, actually. It'll get fixed, to the extent that we intend to fix it, when we remove version numbers from filenames (they are already mangled on to symbols) and add version numbers to metadata and source files. I'll bump the priority on this one. |
ghost
assigned
|
Considering the hash change and duplicate-metadata-hash change, there's actually no simple way for us to dodge this experience in the 0.5 timeframe; and it'll realistically be possible in all cases when someone fails to specify a particular version or tighter metadata match-set they're interested in. IOW the problem is more in the ubiquity of statements like Not saying we should avoid trying to mitigate, just that I think as a "bug" it's neither fixable in this timeframe nor necessarily ever fully fixable. It's an ambiguity that's forced on us by the loose coupling implied by underspecified linkage directives. We can only mitigate at most. |
|
Long-term issue; de-milestoning |
|
I think @nikomatsakis intended to close #3235 -- reopening |
Namely, switched in many places to using GNU make provided functions for directory listing and text processing, rather than spawning a shell process to do that work. In the process of the revision, learned about Target-specific variables, which were very applicable to INSTALL_LIB (which, on a per-recipe basis, was always receiving the same actual arguments for its first two formal parameters in every invocation). http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html (We might be able to make use of those in future refactorings.) ---- Also adds a cleanup pass to get-snapshot.py as well, since the same problem arises when we unpack libraries from the snapshot archive into a build directory with a prior snapshot's artifacts. (I put this step into the python script rather than the makefile because I wanted to delay the cleanup pass until after we have at least successfully downloaded the tarball. That way, if the download fails, you should not destroy the previous unarchived snapshot libraries and build products.) ---- Also reverted whitespace changes to minimize diff. I plan to put them back in in a dedicated commit elsewhere.
This is a small follow-up fix to the previous commit: I needed to quote the right-hand side of the definition for the variable MATCHES, to handle the case where there are more than one previously installed libraries in the target directory.
…-issue3225-safeguarded, r=graydon When building Rust libraries (e.g. librustc, libstd, etc), checks for and verbosely removes previous build products before invoking rustc. (Also, when Make variable VERBOSE is defined, it will list all of the libraries matching the object library's glob after the rustc invocation has completed.) When installing Rust libraries, checks for previous libraries in target install directory, but does not remove them. The thinking behind these two different modes of operation is that the installation target, unlike the build tree, is not under the control of this infrastructure and it is not up to this Makefile to decide if the previous libraries should be removed. Fixes #3225 (at least in terms of mitigating the multiple library problem by proactively warning the user about it.)
rewrite_comment: fix block fallback when failing to rewrite an itemized block
add test for uninhabited saved locals in a coroutine adds the test from rust-lang#118871 in Miri as well
Changes required due to: - rust-lang/rust@a34c26e7ec Make body_owned_by return the body directly. - rust-lang/rust@333458c2cb Uplift TypeRelation and Relate - rust-lang/rust@459ce3f6bb Add an intrinsic for `ptr::metadata` - rust-lang/rust@7e08f80b34 Split smir `Const` into `TyConst` and `MirConst` - rust-lang/rust@eb584a23bf offset_of: allow (unstably) taking the offset of slice tail fields - rust-lang/rust@16e8803579 Update cargo Resolves: rust-lang#3218
If you do
make installwith previous installed versions, multiple copies of all the libraries get left in (for me)/usr/local/lib/rustc/x86_64-apple-darwin/lib. Then the next time you try building something with the installed rustc, it'll promptly fail witherror: multiple matching crates for coreThe text was updated successfully, but these errors were encountered: