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

Bootstrap cargo crashes on i486 machine #54740

Open
djc opened this issue Oct 2, 2018 · 10 comments
Open

Bootstrap cargo crashes on i486 machine #54740

djc opened this issue Oct 2, 2018 · 10 comments

Comments

@djc
Copy link
Contributor

@djc djc commented Oct 2, 2018

I have a user who sees the stage0 cargo crash:

running: /var/tmp/portage/dev-lang/rust-1.25.0/work/rust-stage0/bin/cargo build --manifest-path /var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/Cargo.toml --verbose --verbose --locked --frozen
Traceback (most recent call last):
  File "./x.py", line 20, in <module>
    bootstrap.main()
  File "/var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/bootstrap.py", line 763, in main
    bootstrap()
  File "/var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/bootstrap.py", line 743, in bootstrap
    build.build_bootstrap()
  File "/var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/bootstrap.py", line 621, in build_bootstrap
    run(args, env=env, verbose=self.verbose)
  File "/var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/bootstrap.py", line 148, in run
    raise RuntimeError(err)
RuntimeError: failed to run: /var/tmp/portage/dev-lang/rust-1.25.0/work/rust-stage0/bin/cargo build --manifest-path /var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/Cargo.toml --verbose --verbose --locked --frozen

(BTW, it would be nice if that error was improved to have a few more details about how the command failed to run.)

The user hypothesizes that this might be due to cargo being with SSE2, which his machine (which has an Athlon MP 2800+) does not support.

(From a downstream bug report.)

@Mark-Simulacrum do you happen to know about this stuff?

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

@Mark-Simulacrum Mark-Simulacrum commented Oct 2, 2018

@alexcrichton is more familiar with the details of platform support, I think. However, I suspect we are indeed possible not building the binary with the proper architecture -- I think it's feasible that we could change things there, but even if so, such a change would likely only land in 1.31 stable at the earliest.

@alexcrichton

This comment has been minimized.

Copy link
Member

@alexcrichton alexcrichton commented Oct 2, 2018

This is expected currently, we don't have bootstrap compilers for anything less than i686

@djc

This comment has been minimized.

Copy link
Contributor Author

@djc djc commented Oct 2, 2018

So is it fair to say non-SSE2 is currently not part of the tier 1 x86 support? Or are the bootstrap binaries different somehow from the x86 release binaries?

@alexcrichton

This comment has been minimized.

Copy link
Member

@alexcrichton alexcrichton commented Oct 2, 2018

The tier distinction doesn't really come into play here per se, it's just that we don't produce cargo/rustc binaries for i586-unknown-linux-gnu, which is our "non-see2" target

@djc

This comment has been minimized.

Copy link
Contributor Author

@djc djc commented Oct 3, 2018

Okay, so my user is actually on i486-unknown-linux-gnu or i586-unknown-linux-gnu, which means there are no rustc or cargo binaries and they'd have to cross-compile their binaries?

@leio

This comment has been minimized.

Copy link

@leio leio commented Oct 3, 2018

This is expected currently, we don't have bootstrap compilers for anything less than i686

But i686 doesn't mean SSE2. SSE2 is an additional instruction set over i686.
The downstream user is running i686-unknown-linux-gnu.
After further pondering of previous comments, I understand your current i686 builds are really i686-sse2 builds, hence the issue.
Perhaps this could change, or if not, at least https://forge.rust-lang.org/platform-support.html and other places mention it explicitly, as i686 does NOT imply SSE2.

@alexcrichton

This comment has been minimized.

Copy link
Member

@alexcrichton alexcrichton commented Oct 3, 2018

@djc correct yeah

@leio it does mean sse2 for clang and rust though!

@leio

This comment has been minimized.

Copy link

@leio leio commented Oct 3, 2018

@alexcrichton Yes, most unfortunate. Maybe you didn't see some of my comment edits, but basically I think this should be more more clear then. Also, I don't see how clang has anything to do with it - it builds non-SSE2 binaries just fine to the best of my knowledge. All I can find is that it might pentium4 or some such with SSE2 if you don't specify -march=i686.
See also e.g. https://internals.rust-lang.org/t/is-pentium4-still-an-appropriate-base-cpu-for-i686/7353/6 and the following comment. i686 doesn't mean SSE2 - don't name things as such when you require SSE2. At the very least, the supported platform and other pages should be clear on this then, meaning that without SSE2 it's not tier1, as you need to bootstrap yourself.

@alexcrichton

This comment has been minimized.

Copy link
Member

@alexcrichton alexcrichton commented Oct 3, 2018

@leio we match clang:

$ rustc --target i686-unknown-linux-gnu --print cfg | grep sse2
target_feature="sse2"
$ clang -x c -target i686-unknown-linux-gnu -emit-llvm -S -o - - <<< "void foo() {}" | grep sse2
attributes #0 = { ... "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" ... }

You can build Rust for 32-bit x86 targets without sse2, and you can probably build a whole compiler as well, we just don't ship precompiled binaries. It should be fine to update documentation!

@leio

This comment has been minimized.

Copy link

@leio leio commented Oct 3, 2018

clang has a default for that target; but -march=i686 is what is used by people - and distributions building their packages that have decided to support all i686. The problem with rust is, that it doesn't just mean what the default is - it means you can't even bootstrap it from the binaries provided under the i686 banner. Those binaries should explicitly state they require SSE2 in their naming, or at least documentation.
Anyhow, we are on the same page now, but unfortunately I don't personally have the energy to clone various documentation repos and file PRs, so I hope that can be handled by someone more familiar with the subject matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.