Bootstrap cargo crashes on i486 machine

[djc]

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]

@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 is expected currently, we don't have bootstrap compilers for anything less than i686

[djc]

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]

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]

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 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]

@djc correct yeah

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

[leio]

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

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

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.

[steveklabnik]

It's been a while. Is this still an issue?

[jyn514]

My understanding is that the crash happens because we assume that i686 supports SSE2, but that's not true for i486 targets. https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Lower.20baseline.20expectations.20for.20i686.20unix.E2.80.A6.20compiler-team.23548 is a current MCP for changing that assumption.

In the meantime I think it would be reasonable to document the assumption, but I don't think the behavior needs to change.