Change:
Ok(TargetTriple::TargetPath(canonicalized_path)) } <ins> /// Creates a target triple from its alias pub fn from_alias(triple: String) -> Self { macro_rules! target_aliases { ( $(($alias:literal, $target:literal ),)+ ) => { match triple.as_str() { $( $alias => TargetTriple::from_triple($target), )+ _ => TargetTriple::TargetTriple(triple), } } } target_aliases! { // `x86_64-pc-solaris` is an alias for `x86_64_sun_solaris` for backwards compatibility reasons. // (See <https://github.com/rust-lang/rust/issues/40531>.) ("x86_64-pc-solaris", "x86_64-sun-solaris"), } } </ins> /// Returns a string triple for this target. /// /// If this target is a path, the file name (without extension) is returned.

Discussion:
This was caused by: And originally reported there too:
, I have crated new bug to truck the issue. Can you please elaborate what exactly needs to be done in per ?
I haven't got time to look into this just now, but I would have thought it wouldn't be too difficult to track down what's going on here. and ought to be aliases, but only one of them works — so we just need to figure out where one isn't being treated like the other.
I have tried add symbolic link as follows: But it doesn't help much: It seems that libstd- expects just x86_64-sun-solaris. any idea?
I did try having a look, but I think I'd need to actually start debugging to figure out where the issue arises. The error message is being emitted from: which gives a starting point: it should be behaving identically regardless of the two targets. Though I would like to see this fixed, I don't have a lot of time at the moment, and I don't think it's an important issue, as you can use the alias instead. So I don't think I can dig into this myself.
I looked into this and probably found out why this is happening. The above condition fails because while is set to what is passed as (in this case ), is set during the compilation (as is described here): Similar code where is being compared with appears in several places and the compiler then incorrectly assumes that it is cross compiling: and it cannot find the target to compile against. Changes from the possibility to use in case that we compile rustc as such, but didn't solve that those two should be assumed the same. I managed to fix this by changing to as soon as possible during the runtime. I managed to do so with the addition of the following code into : /// Creates a target triple from it's alias pub fn fromalias(triple: String) -Self { match () { "x8664-pc-solaris" =TargetTriple::fromtriple("x8664-sun-solaris"), =TargetTriple::TargetTriple(triple), } } and then called this as soon as possible (in the function when command line options are being parsed). However, I see that this might not be the best way of implementing this.

There is probably a better place in code to do this, or you might prefer addition of better support for aliases. I don't see into this compiler code much, this is just the first feasible thing that worked for me.
thanks for investigating! At the moment, this is the only alias, so I think that special casing it like this is fine. If it turned out that we wanted to add more in the future, we could think about revisiting the solution. I'd be happy to review your fix if you opened a pull request.
One more question: would you be interested in PR, which makes the default target and its alias and also builds whole rustc as ? Because even with this fix, e.g. firefox won't get pass configure because it compares the output from (which remains as it is configured as such during the rust build) with the host triplet determined as the best candidate (which is , because it is the correct one for this platform) and hence fails. While this is more of a firefox bug rather than a rust issue, I think that making the default one would fix many similar problems while keeping the backward compatibility by making its alias.
perhaps that would be a good idea, yes. Then the default target would match the LLVM target, which is what was probably intended from the start. Thanks!