Please answer to pkg-rust-maintain...@lists.alioth.debian.org. Don't answer to debian-ports@l.d.o (just let your mail client honor the Reply-To field).
Hello! I would like to a quick heads-up regarding the architecture status of Rust after having had at the possibilities to get it bootstrapped for the remaining architectures in Debian. This is as of Rust 1.24. alpha ===== Status: No port yet. But until around version version 3.1, LLVM used to have an official port for Alpha. So porting LLVM and consequently to Alpha should generally feasible if LLVM upstream would be willing to merge an Alpha port of LLVM back in. armel ===== Status: Is generally supported; pre-compiled binaries from the Rust website work but trying to bootstrap the Debian package results in LLVM bailing out with: "LLVM ERROR: Broken function found, compilation aborted!" Necessary work: Can be most likely get to work by using the embedded copy of LLVM instead of Debian's llvm-toolchain-4.0 package. See also powerpc. hppa ==== Status: Currently no LLVM port that I know of. mrustc might be an alternative. ia64 ==== Status: Same as for Alpha. The ia64 port of LLVM was never officially merged though. But it was done by the original LLVM compiler team though when ia64 was still cool. m68k ==== Status: I started adding the necessary bits and pieces in a branch for the Rust compiler but since there is no complete LLVM port for m68k yet, porting Rust to m68k is currently not possible. I'm very confident it will happen in the future though. We might be able to use mrustc in the meantime which compiles Rust code to C code which can then be compiled using gcc. Necessary work: - https://github.com/M680x0/M680x0-llvm/blob/M680x0/lib/Target/M680x0/TODO.md - Finish the work I started on Rust for m68k and get it merged upstream mips ==== Status: Both pre-compiled as well as freshly compiled binaries of the Rust compiler crash quite early when trying to build the Rust compiler natively on mips. See: http://paste.debian.net/1011381/ Necessary work: Fix the above crash. Could also be a bug in LLVM. mips64el ======== Status: Rust compiler seems generally relatively stable and compiling the compiler natively on mips64el will progress quite far but the linker will eventually bail out with "error adding symbols: Bad value" (I accidentally pasted the full backtrace into a pastebin with an expiration date :(). Necessary: Fix the above crash. Could also be a bug in LLVM or binutils. mipsel ====== Not tested. Most likely similar behavior as on mips. powerpc ======= Status: Trying to bootstrap the Rust compiler Debian package using Debian's LLVM compiler through the llvm-toolchain-4.0 package eventually bails out with: "LLVM ERROR: Broken function found, compilation aborted!" (same as error as on armel). Switching the Debian compiler to use the internal LLVM copy let's the build almost finish. The build eventually fails with Rust's fabricate tool crashing with an overflow. powerpcspe ========== Status: No official port. But since LLVM supports the SPE CPU extensions on PowerPCSPE adding support for this architecture should be any more complex than it was to add x32 support to Rust. Otherwise, the compiler is expected to suffer from the same bugs as on powerpc. sparc ===== Status: Some pieces were missing in Rust upstream which I have opened a pull request for. Additional small changes will be necessary in packages like cc-rs and possibly libc (the Rust package). Otherwise, it should be as usable as Rust on sparc64. I expect Rust on 32-bit sparc to become usable once the Gentoo folks get around bootstrapping it. They're currently busy fixing their sparc port. Necessary work: Get missing pieces merged upstream. Actually bootstrap the compiler. sparc64 ======= Status: As of version 1.24, the compiler is very stable and can be used to compile itself, Cargo and the Rust code in Firefox and Thunderbird. It has been bootstrapped in Debian. However, both the testsuites for rustc and cargo do not pass all tests on sparc64. Although, to be fair, the amount of tests in both testsuites is crazy and SPARC might simply have some peculiarities that the Rust people haven't been thinking about. SPARC has always been the special snowflake of architectures when it comes to otherwise subtle bugs. Necessary work: Fix the testsuites for rustc and cargo and make sure the issues are resolved for sparc (32-bit) as well. For the time being, the testsuites for cargo and rustc should be ignored/disabled on sparc64. x32 === Status: Compiler mostly works and can be used to build cargo but not itself, crashes with: http://paste.debian.net/1011382/. Also, crates like "time" and "filetime" still suffer from the fact that x32 is a 32-bit architecture with a 64-bit kernel interface (see: https://sourceware.org/bugzilla/show_bug.cgi?id=16437). As a result, using libc::c_long doesn't work. We have to use "i64" on x32 instead. Necessary work: Fix the crash above. Also, get D43630 (https://reviews.llvm.org/D43630) merged in LLVM upstream. Fix the remaining 64-bit time issues in crates like "filetime" and "time". Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
