cross fails to recompile build script correctly when there are project changes

[hcldan]

Checklist

• I've looked through the issues and pull requests for similar reports

Describe your issue

My first compile works great. I'm having it use a custom build ubi7 image with rustup installed.
I need an older version of glibc to link against.

When I edit a file and try to re-build, I get an error that the build script can't run because I don't have the correct glibc version:

error: failed to run custom build command for `project v0.1.0 (/home/user/git/project)`

Caused by:
  process didn't exit successfully: `/target/debug/build/project-de133d924a686ebc/build-script-build` (exit status: 1)
  --- stderr
  /target/debug/build/project-de133d924a686ebc/build-script-build: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /target/debug/build/project-de133d924a686ebc/build-script-build)
  /target/debug/build/project-de133d924a686ebc/build-script-build: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /target/debug/build/project-de133d924a686ebc/build-script-build)
  /target/debug/build/project-de133d924a686ebc/build-script-build: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /target/debug/build/project-de133d924a686ebc/build-script-build)
  /target/debug/build/project-de133d924a686ebc/build-script-build: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /target/debug/build/project-de133d924a686ebc/build-script-build)
  /target/debug/build/project-de133d924a686ebc/build-script-build: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /target/debug/build/project-de133d924a686ebc/build-script-build)

I am doing this in WSL2(Ubuntu) in Windows 11

So it looks to me like something saw I needed to recompile stuff, re-compiled my build.rs on the host machine, and then tries to run it in the docker container.

What target(s) are you cross-compiling for?

x86_64-unknown-linux-gnu

Which operating system is the host (e.g computer cross is on) running?

• macOS
• Windows
• Linux / BSD
• other OS (specify in description)

What architecture is the host?

• x86_64 / AMD64
• arm32
• arm64 (including Mac M1)

What container engine is cross using?

• docker
• podman
• other container engine (specify in description)

cross version

cross 0.2.4 (8d8d84b 2022-09-08)

Example

No response

Additional information / notes

No response

[Alexhuszagh]

Duplicate of #724, unfortunately, this isn't a cross issue but an upstream bug. Since of how cross works, however, we're a canary in the coal mine and this triggers much more frequently than other use-cases. The solution is to run cargo clean. I wish there was a better alternative.

[hcldan]

@Alexhuszagh I've looked through the contents of the linked issues (thank you, by the way, I missed your open issue).
What I'm not understanding here is that the build script is compiled in the docker container the first time... otherwise the first build wouldn't work, right?

On the subsequent build, the scripts look to have been recompiled, but cross didn't do it this time.
Is there no way for cross to get in front of that, or to make sure the build script is compiled in the container each time?

[Alexhuszagh]

We only execute cargo in the container, but it's an issue with fingerprinting I believe where they don't want a full recompile even if rustc changes. See rust-lang/cargo#10367 (comment). Another solution is to use a custom target directory for each target (--target-dir path/to/x).

[Alexhuszagh]

I've updated that linked issue description to make the issue somewhat clearer, as well as possible solutions.

[hcldan]

@Alexhuszagh Ok but I'm not doing any other builds in between.. why do you think rustc is changing?
Is my dev env compiling things for me with my host env?

[Emilgardis]

do you have rust-analyzer or something else that builds the project in the background?

[hcldan]

yeah that's probably it... I'm using vscode and that plugin... can that work with cross?

[Alexhuszagh]

yeah that's probably it... I'm using vscode and that plugin... can that work with cross?

It can, it just makes it more likely to cause the above issue. It's unfortunate, since there's not much we can do about it (except exporting CARGO_TARGET_DIR or using --target-dir is a great workaround). Just make sure that envvar is in your shell that you invoke cross in, but not available to rust-analyzer.