Advertising

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