Add target triplet next to host in rustc -vV output

[boris-kolpackov]

I would like to propose adding the comiler's target triplet next to the host triplet in the rustc -vV output. Specifically, currently (as of 1.62) the output looks like this:

$ rustc -vV
rustc 1.62.1
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.62.1
LLVM version: 14.0.6

I propose to change this to print:

$ rustc -vV
rustc 1.62.1
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
release: 1.62.1
LLVM version: 14.0.6

$ rustc --target i686-unknown-linux-gnu -vV
rustc 1.62.1
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
target: i686-unknown-linux-gnu
release: 1.62.1
LLVM version: 14.0.6

The value for the target line will be the same as llvm-target in the --print target-spec-json output.

Here is the motivation for this addition:

1. Currently, AFAIK, the only way to get this information is with the --print target-spec-json option which is unstable. This means one can only use it on the nightly compiler (or resort to the RUSTC_BOOTSTRAP=1 hacks). While there is desire to stabilize this option (see Tracking issue to stabilize --print target-spec-json #38338), the progress has been slow and it's currently blocked on design concerns.

2. Even if/when --print target-spec-json is stabilized, it would still be beneficial to provide the target triplet as part of the -vV output because that would allow getting the commonly needed information (compiler version and target) with a single compiler invocation. As it is currently, in the build system I work on (build2), we have to make two compiler invocations to get this information.

3. It appears that some users are confusing the host triplet (as printed in -vV) for target. For example, see answers to this StackOverflow question. By printing both we will hopefully make people pause and contemplate the difference.

If this sounds like a good idea, I can try to come up with a PR.

[bjorn3]

How would this work with non-LLVM backends? Those can have their own names for targets entirely separate from what LLVM calls them. Also in the case of that stackoverflow question the user did actually want the rust triple which is already printed by rustc -vV, not the LLVM triple.

As it is currently, in the build system I work on (build2), we have to make two compiler invocations to get this information.

What do you need the LLVM triple for? Passing it to rustc as --target is not valid. For example the rust triple riscv32gc-unknown-linux-gnu corresponds to the LLVM triple riscv32-unknown-linux-gnu. Note the missing "gc" after "riscv32".

[boris-kolpackov]

How would this work with non-LLVM backends? Those can have their own names for targets entirely separate from what LLVM calls them.

While it's true the format of "target triplet" is not precisely documented, most backends will have some sensible variant of it. For example, for GCC:

$ gcc -dumpmachine
x86_64-linux-gnu

Also in the case of that stackoverflow question the user did actually want the rust triple which is already printed by rustc -vV, not the LLVM triple.

I believe there are two different dichotomies here: the exact target triplet format, as in "Rust triplet" vs "LLVM triplet" (vs, I guess, "GNU triplet", as printed by config.guess/config.sub), and the host vs target triplet. What rustc -vV prints is the triplet that identifies the machine on which rustc is supposed to run (or, in other terms, of the machine on which it is supposed to be hosted) while what the author of that StackOverflow was asking is the triplet of the machine for which rustc is compiling.

I am not too attached to the exact format of the target triplet that would be printed by rustc -vV. If it makes more sense to print "Rust triplet" instead of "LLVM triplet", then I am happy to go this route.

What do you need the LLVM triple for?

While #38338 has more background on my use-case, in a nutshell, a build system that I am working on needs to know which platform is being targeted by rustc. This information is necessary for various decisions, ranging from which file extensions to use for output to making sure the targets of rustc and, say, C/C++ compiler match. I don't particularly care which exact format of the target triplet is being used here since we have to do some normalization a-la config.sub in any case.

[bjorn3]

What rustc -vV prints is the triplet that identifies the machine on which rustc is supposed to run

It identifies the default target which is always the same as the host triple:

rust/compiler/rustc_session/src/config.rs

Lines 1845 to 1859 in 2176e3a

	pub fn parse_target_triple(
	matches: &getopts::Matches,
	error_format: ErrorOutputType,
	) -> TargetTriple {
	match matches.opt_str("target") {
	Some(target) if target.ends_with(".json") => {
	let path = Path::new(&target);
	TargetTriple::from_path(path).unwrap_or_else(|_| {
	early_error(error_format, &format!("target file {path:?} does not exist"))
	})
	}
	Some(target) => TargetTriple::TargetTriple(target),
	_ => TargetTriple::from_triple(host_triple()),
	}
	}

It can't be any different as otherwise proc macros would break as those are compiled with the default target by cargo and proc macros need to compiled for the same target as rustc itself for rustc to be able to load them. The only case where host and target are different for rustc is when you explicitly pass --target to tell it to use a different triple as target.

This information is necessary for various decisions, ranging from which file extensions to use for output to making sure the targets of rustc and, say, C/C++ compiler match.

For the first one cargo uses rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro (and adds --target is you pass --target to cargo) which shows exactly what every output file is named. For example on my x86_64-unknown-linux-gnu system that is:

___
lib___.rlib
lib___.so
lib___.so
lib___.a
lib___.so

For the second one, asking the user to specify it is the only accurate way. While rust triples often look like gcc or llvm ones, this is not always the case. i686-apple-darwin is i386-apple-darwin according to gcc. aarch64-apple-ios-sim is aarch64-apple-ios7.0-simulator according to clang (or other versions depending on IPHONEOS_DEPLOYMENT_TARGET). Take a look at the cc crate for more examples of arbitrary mappings: https://github.com/rust-lang/cc-rs/blob/main/src/lib.rs Many of them don't match either the rust triple or the triple passed to llvm by rustc so getting access to both is not as useful as you may think.

[boris-kolpackov]

The only case where host and target are different for rustc is when you explicitly pass --target to tell it to use a different triple as target.

Yes, I think you are right. I was under the impression that one can change the default target with rustup default <toolchain>-<triplet> but it looks like this changes the host, not (only) the (default) target. So one can determine rustc's target by examining the command line for --target (not forgetting to handle both --target=X and --target X forms ) and if one is not found, falling back to host.

While I believe there is still some value in my proposal (i.e., one doesn't have to analyze the command line manually), it is quite diminished and I would understand if it's not viewed as worthy of the trouble.

[CAD97]

While I'm sympathetic to "make it clearer," the expectation for a target triple comes from the gcc-ism of cross compilers being an exception rather than the norm. rustc is fundamentally a cross compiler, so there is no target configuration to rustc other than what host architecture it's built for.

[jyn514]

I'm going to close this; the only way to compile to a target other than the host is to pass --target, at which point the user already knows which target they're compiling to.