Two steps relase build in docker produces noop binary

[mverleg]

Steps

TLDR version:

• clone https://github.com/markKL1/java_gym_1_rust_solution --branch binary_noop_issue
• docker build -t rust_gym_1 . && docker run rust_gym_1

Long version:

I have a Dockerfile like this:

FROM rust:1.36.0
WORKDIR /code/gym/
COPY Cargo.toml .
RUN mkdir "src" && echo "fn main() {}" > "src/main.rs"
RUN cargo build --release
COPY src/ ./src/
RUN cargo build --release
CMD ["cargo", "run", "--release"]

(Where the two builds are for caching (#2644) so I want to keep that.)

Cargo.toml:

[package]
name = "rust_gym_1"
version = "1.0.0"
authors = ["Mark"]
edition = "2018"
[dependencies]
rayon = "1.1.0"

src/main.rs:

fn main() {
    println!("Welcome to Rust gym 1");
}

Then I run (in Bash):

docker build -t rust_gym_1 . && docker run rust_gym_1

Problem

This build succeeds, but the executable does nothing, just exits without any output and with exit code 0.

Successfully tagged rust_gym_1:latest
    Finished release [optimized] target(s) in 0.01s
     Running `target/release/rust_gym_1`

Analysis

I have found things that fix it:

• Don't use caching (only one build).
• touch a source file and build a third time.
• Use debug mode instead

The code inside main does not seem to have any effect, I started with a few hundred lines but now I just have a logging statement and it still happens.

It's not just stdout that's broken, the runtime was also way too short to be executing the original code.

But on my local system, if I don't do one of the above, I consistently get a binary that does nothing.

It might be platform dependent - I could swear a very similar Dockerfile worked on Windows, but now it's failing on Ubuntu. But I am no longer near the Windows machine so I can't verify this.

Notes

Output of cargo version: cargo 1.36.0 (c4fcfb7 2019-05-15)

Linking info (possibly related issue):

$ ldd target/release/rust_gym_1
linux-vdso.so.1 (0x00007ffc273b5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7400b2a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7400922000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7400705000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f74004ee000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f740014f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7400f5d000)

This seems like a pretty nasty issue to debug, and at the same time pretty niche...

I'm not sure if it's Docker or Cargo or something else.

[ehuss]

Cargo detects if it needs to rebuild based on mtime of the files. Your dummy main.rs has a timestamp newer than the source added by the COPY command (AFAIK, COPY retains the original timestamps). You'll need to add something like touch src/main.rs after copying to ensure that the timestamp is newer than the dummy.

[mverleg]

Ow that makes a lot of sense, I overlooked that. I had previously used the same setup with multiple source files and never thought about it breaking down if it's just main.rs. Thanks!