run-make cross-compilation support is questionable

[Noratrieb]

I observed this in https://github.com/rust-lang-ci/rust/actions/runs/13336646227/job/37253280174.

Basically, when you do rustc() in rmake.rs, it will always compile for the host (unless you explicitly pass a target). This is surprising, because that is not what you asked for when running cross-tests. This means that cross-testing is much less effective than host testing and misses many tests. It is by no means expected that cross-testing will be as good as host testing, but tests incompatible with it should at least be labelled ignore-cross-compile (as many are already) to be clearer about this.

But it's not just a lack of testing, as seen in the CI run above, I got this error when running gnu->musl cross tests:

/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/raw-dylib-elf-verbatim/rmake_out/main: error while loading shared libraries: /lib/x86_64-linux-gnu/libc.so: invalid ELF header

Without investigating it further, it seems like this is caused by rustc() compiling for the host (GNU) while some stuff does correctly use musl.

I suggest that rustc() and other build commands (including native C builds) automatically pass a --target explicitly (or manage to build for the correct target through other means for C). If this is not possible, there should be an error and the test should be marked as ignore-cross-compile to ensure binaries are always compiled for and tested with the correct target.

[Kobzol]

We independently discovered this in #137373 😆 After that PR, we can try to automatically configure --target for rustc invocations, as compiletest should now hopefully only pass the required target directory paths correctly, rather than host + target dirs.