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

Compiler doesn't actually write output if rerun quickly #18913

Closed
alexcrichton opened this issue Nov 13, 2014 · 1 comment · Fixed by #25411
Closed

Compiler doesn't actually write output if rerun quickly #18913

alexcrichton opened this issue Nov 13, 2014 · 1 comment · Fixed by #25411
Labels
A-linkage Area: linking into static, shared libraries and binaries

Comments

@alexcrichton
Copy link
Member

I have a suspicion that we're not calling ar correctly if an rlib previously existed. This script, for example, prints 0 both times:

echo 'extern crate foo; fn main() { println!("{}", foo::foo()); }' > bar.rs
echo 'pub fn foo() -> int { 0 }' > foo.rs
rustc foo.rs --crate-type lib
rustc bar.rs -L .
./bar

echo 'pub fn foo() -> int { 1 }' > foo.rs
rustc foo.rs --crate-type lib
rustc bar.rs -L .
./bar

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.

@alexcrichton alexcrichton added the A-linkage Area: linking into static, shared libraries and binaries label Nov 13, 2014
@nodakai
Copy link
Contributor

nodakai commented Nov 13, 2014

I think the u option given to ar doesn't examine timestamps with sub-second accuracy and thus sometimes ignores the new object file.

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
Labels
A-linkage Area: linking into static, shared libraries and binaries
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants