3 ms·

For the Rustaceans in the thread, I've been wondering - What's the current state of affairs of Rust for non-x86_64 targets? I know it's in flux, and that docume

For the Rustaceans in the thread, I've been wondering - What's the current state of affairs of Rust for non-x86_64 targets? I know it's in flux, and that documentation isn't always up to date. What architectures can rustc target? Can it cross-compile? Can I cross-compile rustc itself, or do a Canadian-cross (where I cross-compile a rustc that wants to target a different architecture than the one that hosts the compiler)? Speaking as somebody who does a ton of system programming for embedded Linux systems, this is basically C/C++'s biggest advantage over Rust - the extreme flexibility of the available toolchains.

fnord123 6y ago
https://forge.rust-lang.org/release/platform-support.html https://forge.rust-lang.org/release/platform-support.html https://github.com/japaric/rust-cross https://github.com/japaric/rust-cross
steveklabnik 6y ago
Every Rust compiler is a cross compiler. There can be some issues on some combinations of cross compiling, that is like, you can't run link.exe on a Mac so cross compiling from a Mac to Windows only works if you don't use the msvc target, stuff like that. I personally work on embedded ARM stuff on Windows, so I'm cross compiling from x86_64-pc-windows-gnu to thumbv7em-none-eabihf all the time. No need for a special build or setup, just a "rustup target add thumbv7em-none-eabihf && cargo build --target=thumbv7em-none-eabihf" and that's it. ARM themselves are committing to getting the various ARM targets to Tier 1 support. AVR support landed in nightly recently. Other targets have less support, but that's mostly due to lack of people power, not a lack of interest from us.
- Arnavion 6y ago
  I know you know this, but just to clarify for other people, "Every Rust compiler is a cross compiler" is only true for pure Rust code. You'll still need a C cross-compiler toolchain to link your final binary, and any Rust libraries that are bindings to external libraries and expect those libraries' C headers / link objects to be pre-installed [1] will need said external libraries' C headers / link objects to be available for the target architecture. So the availability of a C cross-compiler toolchain can affect your ability to compile Rust code for foreign architectures. As a concrete example, at $dayjob we need to compile our code for CentOS 7 armv7 and aarch64, but CentOS 7 does not have a usable cross-compiler toolchain in its repos [2], so we have to run the build process in a centos7 arm container running under qemu. [1]: Eg openssl-sys is bindings to openssl and expects you to have installed the equivalent of your distro's openssl-devel package. In cross-compilation scenarios, this means installing the openssl-devel package for the foreign arch. For debian you'd do something like `dpkg --add-architecture armhf; apt install libssl-dev:armhf` [2]: What it has is only for cross-compiling the kernel, so there's no cross glibc available to link the final binary to.
  - steveklabnik 6y ago
    Ah yes, thank you. I should make sure to clarify that better in the future :)
epage 6y ago
You can find the target support levels at https://forge.rust-lang.org/release/platform-support.html https://forge.rust-lang.org/release/platform-support.html
untog 6y ago
I’ve been cross compiling for both Android (x64, i686, arm and arm64) and it works great. Rustup allows you to install additional targets with a simple terminal command. I haven’t tried anything more exotic than that, though.
deleted 6y ago
[deleted]
sitkack 6y ago
ARM is very well supported. I have had zero issues using a Raspberry Pi. As for cross development there is an excellent tutorial targeting the STM32F3DISCOVERY dev board, https://docs.rust-embedded.org/discovery/ https://docs.rust-embedded.org/discovery/ I attended a hack session where the attendees had zero Rust experience and they were able to get blinken led running in under an hour. Basically 10 fullstack web developers were able to open the package on the devkit, install rustup on windows/mac/linux and start writing firmware and updating the board. Pretty solid I'd say.
deleted 6y ago
[deleted]
tedmielczarek 6y ago
The biggest limitation for embedded Rust development tends to be "does LLVM support your CPU?" If not you may be able to hack something together but you're not going to have a great time. If so, there's still a broad range of experiences between "people are actively writing Rust for this board and there are tons of crates exposing the hardware with nice APIs" and "you can get Rust code running on this board". I'm not an embedded developer but I've dabbled enough in the space to believe that Rust is going to do very well there. The development experience is so bad for most existing cases and there aren't a lot of other viable options (unlike for folks writing desktop or server software).

fnord123 6y ago

https://forge.rust-lang.org/release/platform-support.html https://forge.rust-lang.org/release/platform-support.html https://github.com/japaric/rust-cross https://github.com/japaric/rust-cross

steveklabnik 6y ago

Every Rust compiler is a cross compiler. There can be some issues on some combinations of cross compiling, that is like, you can't run link.exe on a Mac so cross compiling from a Mac to Windows only works if you don't use the msvc target, stuff like that. I personally work on embedded ARM stuff on Windows, so I'm cross compiling from x86_64-pc-windows-gnu to thumbv7em-none-eabihf all the time. No need for a special build or setup, just a "rustup target add thumbv7em-none-eabihf && cargo build --target=thumbv7em-none-eabihf" and that's it. ARM themselves are committing to getting the various ARM targets to Tier 1 support. AVR support landed in nightly recently. Other targets have less support, but that's mostly due to lack of people power, not a lack of interest from us.

Arnavion 6y ago
I know you know this, but just to clarify for other people, "Every Rust compiler is a cross compiler" is only true for pure Rust code. You'll still need a C cross-compiler toolchain to link your final binary, and any Rust libraries that are bindings to external libraries and expect those libraries' C headers / link objects to be pre-installed [1] will need said external libraries' C headers / link objects to be available for the target architecture. So the availability of a C cross-compiler toolchain can affect your ability to compile Rust code for foreign architectures. As a concrete example, at $dayjob we need to compile our code for CentOS 7 armv7 and aarch64, but CentOS 7 does not have a usable cross-compiler toolchain in its repos [2], so we have to run the build process in a centos7 arm container running under qemu. [1]: Eg openssl-sys is bindings to openssl and expects you to have installed the equivalent of your distro's openssl-devel package. In cross-compilation scenarios, this means installing the openssl-devel package for the foreign arch. For debian you'd do something like `dpkg --add-architecture armhf; apt install libssl-dev:armhf` [2]: What it has is only for cross-compiling the kernel, so there's no cross glibc available to link the final binary to.
- steveklabnik 6y ago
  Ah yes, thank you. I should make sure to clarify that better in the future :)

epage 6y ago

You can find the target support levels at https://forge.rust-lang.org/release/platform-support.html https://forge.rust-lang.org/release/platform-support.html

untog 6y ago

I’ve been cross compiling for both Android (x64, i686, arm and arm64) and it works great. Rustup allows you to install additional targets with a simple terminal command. I haven’t tried anything more exotic than that, though.

deleted 6y ago

[deleted]

sitkack 6y ago

ARM is very well supported. I have had zero issues using a Raspberry Pi. As for cross development there is an excellent tutorial targeting the STM32F3DISCOVERY dev board, https://docs.rust-embedded.org/discovery/ https://docs.rust-embedded.org/discovery/ I attended a hack session where the attendees had zero Rust experience and they were able to get blinken led running in under an hour. Basically 10 fullstack web developers were able to open the package on the devkit, install rustup on windows/mac/linux and start writing firmware and updating the board. Pretty solid I'd say.

deleted 6y ago

[deleted]

tedmielczarek 6y ago

The biggest limitation for embedded Rust development tends to be "does LLVM support your CPU?" If not you may be able to hack something together but you're not going to have a great time. If so, there's still a broad range of experiences between "people are actively writing Rust for this board and there are tons of crates exposing the hardware with nice APIs" and "you can get Rust code running on this board". I'm not an embedded developer but I've dabbled enough in the space to believe that Rust is going to do very well there. The development experience is so bad for most existing cases and there aren't a lot of other viable options (unlike for folks writing desktop or server software).