Linker and links are ignored with target-applies-to-host and no --target flag

[gmorenz]

Problem

This is the exact same bug as #10744 except with regards to linker and links instead of rustflags and rustdocflags. When building with target-applies-to-host=false and not passing a --target flag linker and links are ignored because the host-values of those are set to the default and then the artifact units end up picking up the host values (see "How it is implemented" in #13900 for an explanation of how that happens).

Steps

Running on x86_64-unknown-linux-gnu (if you have a different host substitute in the correct architecture)

cargo new demo
cd demo
cargo build -Z target-applies-to-host --config target-applies-to-host=false  --config target.x86_64-unknown-linux-gnu.linker="\"nope\""

Expected behavior: error: linker `nope` not found

Actual behavior: It builds without error

cargo new demo
cd demo
echo "int myfunc() {}" | gcc -xc -shared -o libmylib.so -
sed -i '/\[package\]/a links="mylib"' Cargo.toml
echo 'fn main() { panic!("build.rs run") }' > build.rs
cargo build \
    --config 'target.x86_64-unknown-linux-gnu.mylib.rustc-link-lib=["mylib"]' \
    --config 'target.x86_64-unknown-linux-gnu.mylib.rustc-link-search=["native=."]' \
    -Z target-applies-to-host \
    --config target-applies-to-host=false

Expected behavior: It builds without error

Expected bug: It fails to find mylib

Actual behavior:

    Creating binary (application) `demo` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
thread 'main' panicked at src/cargo/core/compiler/custom_build.rs:256:10:
running a script not depending on an actual script
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I.e. cargo crashes as a whole instead of just failing to apply the flags. This only happens in the case where target-applies-to-host=false and no --target flag is passed so it's likely a side effect of failing to apply the flags, but that should be confirmed. I am confident it does fail to apply the flags as well from having been working on the code.

Possible Solution(s)

Extend the fix in #13900 to linker and link overrides. That should fix the expected bugs, but the actual behavior of link overrides causing cargo to panic is a surprise to me and might need something further.

[gmorenz]

@rustbot label: Z-target-applies-to-host

[weihanglo]

I am not @rustbot :P

[gmorenz]

I should say I intend to fix this since it's a natural continuation of what I already fixed, but thought that I should at least create an issue before doing so instead of completely ignoring process.

[gmorenz]

Alright, went ahead and tracked down the root cause of the panic for the links-override half of this issue, tl;dr it is a side effect of failing to properly apply the link overrides flags.

compute_deps_custom_build gets called through compile_ws -> create_bcx (before rebuild_unit_depdendencies) -> build_unit_dependencies --<main path>--> deps_of -> compute_deps -> compute_deps_custom_build, sees that script_override(links, unit.kind) returns Some, and returns that there are no dependencies because it is overridden.

Shortly-therafter rebuild_unit_graph_shared is run, the units kind is changed from Target(host_architecture) to Host.

Much later in the build process build_map gets called through compile_ws -> BuildRunner::compile -> build_map, calls script_override(links, unit.kind) again, and this time gets that there is no override because we haven't overriden the build scripts for host deps. This means it doesn't fill in the build_script_output from the config.

Finally we get around to running the custom build script (compile_ws -> BuildRunner::compile -> compiler::compile -> custom_build::prepare), check if there is a build_script_outputs already, and since there isn't try and run the build-script that we didn't prepare dependencies for. Crashing.

The proposed fix should completely fix this error case, by storing link overrides in the unit instead of looking it up via kind when needed it should no longer be possible to get inconsistent results on whether or not overrides exist.

[weihanglo]

Just re-read this issue. I guess this table is what we are going to fix?
(change in bold text)

	target_applies_to_host=true	target_applies_to_host=false
no --target flag	Flag passed to bin Flag passed to shared dep from bin Linker passed to bin Flag passed to proc macro Flag passed to shared dep from proc macro Linker passed to proc macro Built with 5 invocations Without rustflags, built with 5 invocations	Flag passed to bin Flag passed to shared dep from bin Linker passed to bin (wasn't before) Flag not passed to proc macro Flag not passed to shared dep from proc macro Linker not passed to proc macro Built with 6 invocations Without rustflags, built with 5 invocations

[weihanglo]

If that is the case, then we don't really need to ping the entire team.

[gmorenz]

Yes, exactly that, only modifying behaviour in the top right box.

For completeness that table is missing links-overrides, but it follows the same pattern as linker (or would except that in the top right box it actually just panics cargo right now).