Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rust target x86_64-pc-solaris doesn't work #68214

Closed
psumbera opened this issue Jan 14, 2020 · 8 comments · Fixed by #80073
Closed

rust target x86_64-pc-solaris doesn't work #68214

psumbera opened this issue Jan 14, 2020 · 8 comments · Fixed by #80073
Labels
A-target-specs Area: Compile-target specifications C-bug Category: This is a bug. O-solaris Operating system: Solaris T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@psumbera
Copy link
Contributor

/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)

@jonas-schievink jonas-schievink added C-bug Category: This is a bug. O-solaris Operating system: Solaris labels Jan 14, 2020
@psumbera
Copy link
Contributor Author

@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) ?

@jonas-schievink jonas-schievink added A-target-specs Area: Compile-target specifications T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 14, 2020
@varkor
Copy link
Member

varkor commented Jan 14, 2020

@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
Copy link
Contributor Author

psumbera commented Sep 9, 2020

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
Copy link
Member

varkor commented Sep 12, 2020

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://github.com/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
Copy link
Contributor

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://github.com/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://github.com/rust-lang/rust/blob/a59264b01247836c70e24217e0d346b868387525/src/librustc_metadata/locator.rs#L1028-L1030

and it cannot find the target to compile against.

https://github.com/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
Copy link
Member

varkor commented Dec 14, 2020

@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
Copy link
Contributor

kulikjak commented Dec 16, 2020

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

@bors bors closed this as completed in 0b1e718 Dec 17, 2020
@varkor
Copy link
Member

varkor commented Dec 18, 2020

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

bors added a commit to rust-lang-ci/rust that referenced this issue Mar 1, 2021
…,Mark-Simulacrum

make x86_64-pc-solaris the default target for x86-64 Solaris

This change makes `x86_64-pc-solaris` the default compilation target for x86-64 Solaris/Illumos (based on [this exchange](rust-lang#68214 (comment)) with `@varkor).`

I tried several ways of doing this (leveraging the alias support added with rust-lang#61761 and improved/fixed with rust-lang#80073) and found out that cross-compilation to the new one is by far the simplest way of doing this. It can be achieved by adding the following arguments: `--build x86_64-sun-solaris --host x86_64-pc-solaris --target x86_64-pc-solaris` and enabling the cross compilation with `PKG_CONFIG_ALLOW_CROSS=1` environment variable.

I also removed alias support altogether - `x86_64-pc-solaris` and `x86_64-sun-solaris` are now two separate targets. The problem with aliases is that even if rust internally knows that two are the same, other tools building with rust don't know that, resulting in build issues like the one with firefox mentioned [here](rust-lang#68214 (comment)). I think that once the dust settles and `x86_64-pc-solaris` becomes the default, `x86_64-sun-solaris` can be removed.

If you agree with the above, I have two subsequent questions:
1. Is there a preferred way to display deprecation warnings when `x86_64-sun-solaris` is passed into the compiler as an argument? I am not sure whether target deprecation was done before.
2. Where would be the best way to document this change for those using rust on Solaris? Without the cross-compilation arguments (used once to build a new version), the build won't work. Should I add it into [RELEASES.md](https://github.com/rust-lang/rust/blob/master/RELEASES.md)?

Thanks!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-target-specs Area: Compile-target specifications C-bug Category: This is a bug. O-solaris Operating system: Solaris T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants