rust target x86_64-pc-solaris doesn't work

[psumbera]

/builds/rustc-1.37.0/bin/rustc --target=x86_64-pc-solaris test.rs
ulx-0 17:17 /builds/psumbera/FIREFOX-2/TMP: /builds/rustc-1.37.0/bin/rustc --target=x86_64-pc-solaris test.rs
error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-pc-solaris` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.

This was caused by:
#40531

And originally reported there too:
#40531 (comment)

[psumbera]

@varkor , I have crated new bug to truck the issue. Can you please elaborate what exactly needs to be done in src/tools/build-manifest/src/main.rs per #40531 (comment) ?

[varkor]

@psumbera: 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. x86_64-pc-solaris and x86_64-sun-solaris 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.

[psumbera]

I have tried add symbolic link as follows:

$ ls -l /usr/lib/rustlib/
total 11
-r--r--r--   1 root     bin           50 Aug 28 02:47 components
drwxr-xr-x   2 root     bin            6 Aug 28 02:47 etc
-r--r--r--   1 root     bin            2 Aug 28 02:47 rust-installer-version
lrwxrwxrwx   1 root     root          18 Sep  9 15:57 x86_64-pc-solaris -> x86_64-sun-solaris
drwxr-xr-x   3 root     bin            4 Sep  9 15:57 x86_64-sun-solaris

But it doesn't help much:

$ rustc --target=x86_64-pc-solaris test.rs
error[E0461]: couldn't find crate `std` with expected target triple x86_64-pc-solaris
  |
  = note: the following crate versions were found:
          crate `std`, target triple x86_64-sun-solaris: /usr/lib/rustlib/x86_64-sun-solaris/lib/libstd-560fc60f1e090eba.rlib
          crate `std`, target triple x86_64-sun-solaris: /usr/lib/rustlib/x86_64-sun-solaris/lib/libstd-560fc60f1e090eba.so

error: aborting due to previous error

It seems that libstd-560fc60f1e090eba.rlib expects just x86_64-sun-solaris.

@varkor any idea?

[varkor]

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:
https:/rust-lang/rust/blob/a59264b01247836c70e24217e0d346b868387525/src/librustc_metadata/locator.rs#L486-L490
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.

[kulikjak]

I looked into this and probably found out why this is happening.

The above condition fails because while self.triple is set to what is passed as --target (in this case x86_64-pc-solaris), config::host_triple() is set during the compilation (as is described here):
https:/rust-lang/rust/blob/a59264b01247836c70e24217e0d346b868387525/src/librustc_session/config.rs#L534-L544

Similar code where --target is being compared with config::host_triple() appears in several places and the compiler then incorrectly assumes that it is cross compiling:

https:/rust-lang/rust/blob/a59264b01247836c70e24217e0d346b868387525/src/librustc_metadata/locator.rs#L1028-L1030

and it cannot find the target to compile against.

https:/rust-lang/rust/blob/a59264b01247836c70e24217e0d346b868387525/src/librustc_metadata/locator.rs#L1046-L1063

Changes from #61761 added the possibility to use x86_64-pc-solaris 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 x86_64-pc-solaris to x86_64-sun-solaris as soon as possible during the runtime. I managed to do so with the addition of the following code into impl TargetTriple:

/// Creates a target triple from it's alias
pub fn from_alias(triple: String) -> Self {
    match triple.as_str() {
        "x86_64-pc-solaris" => TargetTriple::from_triple("x86_64-sun-solaris"),
        _ => TargetTriple::TargetTriple(triple),
    }
}

and then called this as soon as possible (in the parse_target_triple 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.

[varkor]

@kulikjak: 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.

[kulikjak]

One more question: would you be interested in PR, which makes x86_64-pc-solaris the default target and x86_64-sun-solaris its alias and also builds whole rustc as x86_64-pc-solaris? Because even with this fix, e.g. firefox won't get pass configure because it compares the output from rustc --version --verbose (which remains x86_64-sun-solaris as it is configured as such during the rust build) with the host triplet determined as the best candidate (which is x86_64-pc-solaris, 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 x86_64-pc-solaris the default one would fix many similar problems while keeping the backward compatibility by making x86_64-sun-solaris its alias.

@varkor

[varkor]

@kulikjak: 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!