-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Compiler doesn't actually write output if rerun quickly #18913
Labels
A-linkage
Area: linking into static, shared libraries and binaries
Comments
alexcrichton
added
the
A-linkage
Area: linking into static, shared libraries and binaries
label
Nov 13, 2014
I think the echo 'extern crate foo; fn main() { println!("{}", foo::foo()); }' > bar.rs
echo 'pub fn foo() -> int { 0 }' > foo.rs
strace -f -s 200 -e process -e open rustc foo.rs --crate-type lib
stat libfoo.rlib
rustc bar.rs -L .
./bar
echo 'pub fn foo() -> int { 1 }' > foo.rs
strace -f -s 200 -e process -e open rustc foo.rs --crate-type lib
stat libfoo.rlib
rustc bar.rs -L .
./bar
sleep 1
strace -f -s 200 -e process -e open rustc foo.rs --crate-type lib
stat libfoo.rlib
rustc bar.rs -L .
./bar |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
May 14, 2015
This flag indicates that when files are being replaced or added to archives (the `r` flag) that the new file should not be inserted if it is not newer than the file that already exists in the archive. The compiler never actually has a use case of *not* wanting to insert a file because it already exists, and this causes rlibs to not be updated in some cases when the compiler was re-run too quickly. Closes rust-lang#18913
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
May 26, 2015
This flag indicates that when files are being replaced or added to archives (the `r` flag) that the new file should not be inserted if it is not newer than the file that already exists in the archive. The compiler never actually has a use case of *not* wanting to insert a file because it already exists, and this causes rlibs to not be updated in some cases when the compiler was re-run too quickly. Closes rust-lang#18913
bors
added a commit
that referenced
this issue
May 26, 2015
This flag indicates that when files are being replaced or added to archives (the `r` flag) that the new file should not be inserted if it is not newer than the file that already exists in the archive. The compiler never actually has a use case of *not* wanting to insert a file because it already exists, and this causes rlibs to not be updated in some cases when the compiler was re-run too quickly. Closes #18913
XMPPwocky
pushed a commit
to XMPPwocky/rust
that referenced
this issue
May 29, 2015
This flag indicates that when files are being replaced or added to archives (the `r` flag) that the new file should not be inserted if it is not newer than the file that already exists in the archive. The compiler never actually has a use case of *not* wanting to insert a file because it already exists, and this causes rlibs to not be updated in some cases when the compiler was re-run too quickly. Closes rust-lang#18913
Byron
referenced
this issue
in rust-lang/cargo
Jun 21, 2015
This commit is an architectural change inside of Cargo itself in the way that it handles the output format of builds. Previously when a build start, all existing directories and files would be renamed to `old-foo` folders. The build would then `rename` all files back into the right location as they were seen as fresh and needed for the build. The benefit of a system such as this is a rock-solid guarantee that the build tree contains exactly what it would if we were to start the build from a totally clean directory each time. There are some downsides, however: * In #800, it was discovered that this method has an unfortunate interaction with Docker. Docker apparently will mount many filesystems which `rename` will not work across. * I have seen countless flaky failures on windows due to an attempt to remove a file that was still in use somehow. I've never been able to truly track down why these failures are happening, however. The new system for managing output files is to build up a list of all known files at the start of a build, whitelist any necessary files when the build is being prepared, and then wipe out all unknown files right before the build begins. This is not quite as close to the guarantee as the benefits reaped before because on the second build all build files will still be in their final output locations, they may just get updated as part of the build as well. This seems like an acceptable compromise, however. Closes #800
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a suspicion that we're not calling
ar
correctly if an rlib previously existed. This script, for example, prints0
both times:If I insert
sleep 1
in the middle, this prints 0/1 always, and when run repeatedly it will intermittently print 0/1. I'm currently running this on linux.The text was updated successfully, but these errors were encountered: