I've been using rust on P4 systems with no problems. However, I need to be able to use the compiler on ThinkPad T23 systems (PIII, 1Gb RAM). I realize it would need to swap some, but at the moment the compiler crashes right away with an illegal instruction. I was wondering it was trying to use the floating point unit? The Go compiler needs to be compiled for PIII systems by the user, but with a switch to say to use 386 instructions.
1 Like
I believe the reason is lack of SSE2. You'd need to build rustc with a suitable LLVM target definition.
Are there instructions on how to do that?
You're not the first to ask but maybe you'll be the first motivated enough to pull it off (without an i386 stage0 snapshot available that is). Have a look:
2 Likes
And here:
1 Like
@adaamss3 There aren't instructions but the basic approach I would take is:
- Create a custom target-spec that turns on/off the cpu features you need.
- On a i686-class machine, configure rustc with
./configure --host=i686-unknown-linux-gnu,i686-unknown-linux-gnu-custom, where the latter triple is your custom target. - Build that to create a rustc that will run your i386, and use that compiler with your custom target spec to build additional Rust software.
If you want an i386-compatible rustc that doesn't need a custom target to produce i386-compatible code I think you would need to edit the built-in target spec when building your compiler.
2 Likes
And you could probably just call your custom target i386-unknown-linux-gnu.
1 Like
If that's going to work out of the box, the second step will still require an i686 SSE2 machine to build (because of libstd/librust being linked in). After that you should indeed have a compiler with the desired specs.
Are you sure however no part of either rustc or llvm code has been hardwired for SSE2? I find it strange that an image building effect of, for example, being able to include Rust in the official Slackware distribution (i486/i586) has not been worth the effort basically for a year now.
Some things may not work (e.g. SIMD intrinsics won't be available), but those aren't used by the compiler. As long as all crates you use have a non-SSE2 fallback (for an example, see jetscii), they should work on a rust-i486 target unmodified.
I don't know too much about current Slackware, as it's been about a decade since I last tried it, but Rust has some target systems with bigger market share left out; so it's basically a question of priority (and of course of who is going to do the work).
No, I meant just bare-bones rust tools. Let's not go into crates when it's about having a simple hello world working.
Can we a have a definitive answer along the lines:
"there's absolutely nothing stopping anyone from doing it themselves, not in rustc, not in llvm, not in jemalloc, etc"?
I'm afraid it's not going to be that simple - devoting 30 minutes on fast hardware to cross-compile such a target would've probably been done by someone just for laughs by now.
Slackware is one of the last distributions (or is it the last?) that cater to such old hardware which is why I used it as an example - I know this type of hardware is pretty irrelevant nowadays. (we're talking P3's and Athlons that could still be usable)
1 Like
I think the definitive answer is that we don't know, because nobody tried and reported back.
I was asking the Rust developers familiar with the entire source tree about non-feasibility. Up until a year ago the problem didn't exist so the answer should be easy if some external dependency has forced this policy.
Was this post even necessary?
I am unsure if a Rust developer familiar with the entire source tree exists. Even such a mythical creature probably cannot say for sure if it works. All we can say is no one knows of any obvious reasons why it shouldn't work.
As I said before, building on such machines hasn't been exactly high-priority for Rust. That's not to say it's unimportant work, but no Rust developer with such a machine has invested the time to find out if it works as of yet.
I don't require any effort on anyone's part other than a simple statement why it couldn't be done (if there was a reason). If you are saying with all authority there's no such reason, just conscious policy, great! Then I'd like to try this myself as soon as I manage to wean myself off of this little Odroid C1 that I'm actively testing right now 
And btw, you don't need a physical machine, qemu will suffice. As I'd already mentioned elsewhere you can have a working setup with just qemu-i386 (userspace version) but it doesn't work reliably enough. (and obviously requires qemu to run the binaries it produces)
Anyways all that old hardware keeps getting better and better thanks to Linux. (apart from power consumption, LOL!)
Please don't get me wrong. I cannot state that there is no reason why it wouldn't work. I also cannot say anything with authority here. I'm not even part of the core team; my only foray into rustc code has been applying some refactorings following suggestions from rust-clippy (and a few small things here and there).
All I'm saying is, you have asked, you have more than 180 views on this topic; it's very likely the majority of Rust developers has seen this. No one has come up with a reason why it shouldn't work. @brson himself has given directions how to do it; which indicates that he also knows of no reason why it shouldn't work. That doesn't say it's sure to work out of the box, but we'll never know unless someone steps up and tries.
On a test run I've just attempted to build rustc-1.2.0 with a rustc-1.2.0 release snapshot using qemu-i386 but got this which doesn't look like a qemu issue:
cp: i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/libcompiler-rt.a
rustc: i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/libcore
src/libcore/lib.rs:50:21: 50:47 error: #[feature] may not be used on the stable release channel
src/libcore/lib.rs:50 #![cfg_attr(stage0, feature(custom_attribute))]
and so on a dozen more times.
Passing --release-channel=beta(or nightly) to configure doesn't help. What am I doing wrong?
rustc can't be built with a stable release because it uses a lot of unstable features. A release is not a snapshot.
What exactly are you doing?
Which rustc? You can't use the same stable version to compile itself?
So (I need to use local rust) should I be using a nightly to build 1.2?
You need to be using the appropriate snapshot (why). The i686 snapshot to build the 1.2.0 release seems to be this. The binary should go into i686-unknown-linux-gnu/stage0/bin
Thanks! I was beginning to suspect that much after the latest nightly didn't work either. Even tried to grep the scripts for some sort of snapshot id
As expected qemu-i386 is still not good enough to handle the build (unless
there's a way to force single-threaded rustc operation perhaps?) so I'll
be repeating the whole procedure in full system emulation.
EDIT:
The required stage0 snapshot for rust 1.3 is here.