Different behaviour between cargo build and cargo test

1

Dear All,

I am currently trying to set up a Gitlab CI for my Rust project. Locally, I am using the toolchain x86_64-pc-windows-gnu, and the CI uses x86_64-unknown-linux-gnu. Generally, this should be fine for cargo and rust. After reading some docs, I tried the following:

.cargo/config.toml

[build]
target = "x86_64-pc-windows-gnu" # JDIFF can only be compiled using the gnu target
rustflags = [
    "-C",
    "target-feature=+crt-static",
    "-C",
    "link-self-contained=yes",
]

# for target x86_64-unknown-linux-gnu, clear rustflags
[target.x86_64-unknown-linux-gnu]
rustflags = []

[net]
git-fetch-with-cli = true

The project is built for Windows with the required rust flags by default. If built by the CI, the rust flags should be cleared. This setup works perfectly for Windows (cargo test, cargo build).

However, in the CI, the cargo test --target x86_64-unknown-linux-gnu command fails with the error message "error: option -C link-self-contained is not supported on this target". Strangely, the cargo build command (cargo build --target x86_64-unknown-linux-gnu) succeeds.
Can somebody help me to understand why the config.toml only works for the build and not for the test command?
My current solution is to "clear" the rustflags by manipulating the environment (export CARGO_ENCODED_RUSTFLAGS="").

Has somebody else faced this problem before?

Regards,
Andreas

1 Like
2

I've also anecdotally noticed that different cargo targets can address different subsets of code, a slightly different example: Did feature unification bit me hard?.

The only advice I'd give here, which you may already be doing, is to take the CI aspect out of the loop and test everything locally on windows using a Linux docker. It's so much less painful :-).

I'd also suggest a MRE (Minimal reproducible example - Wikipedia) so people can download and debug locally.

Good luck!