It would be nice to support cross-compilation in the Debian rustc builds, both across-platforms targeting linux and for additional targets in the host platform (eg apple-darwin, assuming its possible to build std without the proprietary apple sysroot), or freebsd/android/etc. I assume the biggest requirement there is just packaging the libstd.
Hi, Note it's already possible to cross-compile to other linux libc platforms, just dpkg --add-architecture $foreign then apt-get install libstd-rust-dev:$foreign. Yes the *only* thing you have to do is package the libstd. I am unlikely to have time for the other platforms you mentioned but am happy to accept patches - just take a look at how the windows/wasm32 stuff how is done in the packaging and copy that. There is also the difficulty in testing the cross-compiled binaries, I personally don't have any Apple systems to test them on, whereas for windows/wasm32 there are emulators you can directly run on Debian. Best, Ximin Matt Corallo:
Some embeded targets would be nice to have For example xtensa-esp32-none-elf xtensa-esp8266-none-elf and some bare arm mcu targets. Having parity with gcc would be nice. For example I have these: gcc-xtensa-lx106 gcc-arm-none-eabi gcc-arm-linux-gnueabihf gcc-12-arm-linux-gnueabihf gcc-mingw-w64-x86-64 gcc-mingw-w64-i686 gcc-mingw-w64-x86-64-posix gcc-mingw-w64-x86-64-win32 gcc-mingw-w64-i686-win32 gcc-mingw-w64-i686-posix gcc-avr (this one is probably not supported by rust, as this is 8 bit platform) I am not planning to be using rust for them, so not a big prio for me. (I use C and D on some of the above with gcc/gdc).
Rust in fact supports AVR (search for AVR in https://doc.rust-lang.org/rustc/platform-support.html), but without std, the topic of this bug.
I don't think that no-std targtets are off topic for this bug. Rust's terminologiy is a bit weird in that "std" sometimes means the "std" crate (which is the thing that does POSIX-style operations), but also sometimes means std+alloc+core (for example in -Zbuild-std=core, which replaces any shipped core with one freshly built -- something one might use instead of having those packaged, except that it will stay a nightly feature for the forseeable future). Thus, it can be argued that even the built libraries would be appropriately named as libstd-rust-dev-thumbv7em-none-eabihf etc -- and even if not (going for libcore-rust-dev-thumbv7em-none-eabihf), the implementation similarities to other platforms without host tools probably warrant lumping them together.