4 ms·

The issue is porting Rust to other architectures, which is not trivial. Work is being done to get there, just not in time for v3.9.

by _ikke_ 8y ago

inferiorhuman 8y ago
Huh? Linux on arm, i686, mips, ppc all have rustup installers. I'm not sure if that formally makes them "Tier 1" platforms but it does mean that they're pretty darn well supported by rust. Are the Alpine folks having problems because they're not using GNU libc?
- _ikke_ 8y ago
  Yes, that most likely plays a role. I wasn't too sure, so I left it out of my answer.
- wyldfire 8y ago
  The challenge might be bootstrapping. rustc makes a habit of capitalizing on just-introduced features, and they only require that you have the prior release. So to build rustc 1.x, you have to build 1.(x-1) first. Also -- packaging. rustup might be available but the distros generally prefer their own native packaging system.
  - inferiorhuman 8y ago
    Yeah I'm somewhat familiar with getting rust bootstrapped, I still have the 15/16/17 rust toolchains built for mipsel kicking around. Worst part of that was targeting wheezy though. It just seems odd that these architectures seem to have official rust support but are being problematic on Alpine. Self-hosting might be a sticking point, but seems a bit of a silly one given how slow some of those architectures are.
  - steveklabnik 8y ago
    When bootstrapping a new arch, you usually cross-compile to get it working. This means that you don't need to build all of those builds. If you want to start a new bootstrap chain, which is what most distros have done, you do this once and then go from there as new releases come out.
- antoinealb 8y ago
  IIRC, at some point rustc was not able to self-host on 32 bit platforms due to the amount of virtual memory it used. I don't know if it has been fixed yet, but I can imagine that this would be an issue if you want your entire package repository to be self-hosting.
deleted 8y ago
[deleted]

The issue is porting Rust to other architectures, which is not trivial. Work is being done to get there, just not in time for v3.9.

by _ikke_ 8y ago

The issue is porting Rust to other architectures, which is not trivial. Work is being done to get there, just not in time for v3.9.

inferiorhuman 8y ago

Huh? Linux on arm, i686, mips, ppc all have rustup installers. I'm not sure if that formally makes them "Tier 1" platforms but it does mean that they're pretty darn well supported by rust. Are the Alpine folks having problems because they're not using GNU libc?

_ikke_ 8y ago
Yes, that most likely plays a role. I wasn't too sure, so I left it out of my answer.
wyldfire 8y ago
The challenge might be bootstrapping. rustc makes a habit of capitalizing on just-introduced features, and they only require that you have the prior release. So to build rustc 1.x, you have to build 1.(x-1) first. Also -- packaging. rustup might be available but the distros generally prefer their own native packaging system.
- inferiorhuman 8y ago
  Yeah I'm somewhat familiar with getting rust bootstrapped, I still have the 15/16/17 rust toolchains built for mipsel kicking around. Worst part of that was targeting wheezy though. It just seems odd that these architectures seem to have official rust support but are being problematic on Alpine. Self-hosting might be a sticking point, but seems a bit of a silly one given how slow some of those architectures are.
- steveklabnik 8y ago
  When bootstrapping a new arch, you usually cross-compile to get it working. This means that you don't need to build all of those builds. If you want to start a new bootstrap chain, which is what most distros have done, you do this once and then go from there as new releases come out.
antoinealb 8y ago
IIRC, at some point rustc was not able to self-host on 32 bit platforms due to the amount of virtual memory it used. I don't know if it has been fixed yet, but I can imagine that this would be an issue if you want your entire package repository to be self-hosting.

deleted 8y ago

[deleted]