Hacker News Reader

Comment by endgame | Hacker News Reader

How is nobody talking about push-button cross-compilation? It could be huge! The only language that I'm aware of that does it at all well is C and that's because the only build tool that does it at all well is automake. But even then the library situation is very hit-and-miss. If rust nails this it's going to be awesome.

View on HN

> push-button cross-compilation? It could be huge! The only language that I'm aware of that does it at all well is C

I'm not familiar with the term 'push-button', but Go also does cross-compilation very well.

(In fact, on Go, technically all compilations are cross-compilations; it just happens that the target platform and architecture may match the platform and architecture of the current machine.)

I'm not sure if that's still the case in 1.5 onwards, since I know they changed some stuff to make it even easier to target other platforms and architectures, but it was the case previously.

I'm pretty sure that the range of platforms for which Go does cross compilation "very well" is quite small. Go has a sizeable runtime, and you need to have a version of the runtime that works on each platform (for exotic platforms you would probably have to write some of the building blocks from scratch). This isn't push-button, this is just "the distribution supports many common platforms"

For example, it seems like compiling to MIPS is not push-button for Go. On the other hand, Rust supports all platforms that LLVM supports, though you need a version of the stdlib compiled for that platform (you don't have to write any code like in the Go case, you just have to compile the sources with the right invocation). For push-button compilation, we just need to distribute these binaries.

I imagine the vast majority of cross-compiles for the core tasks that Go targets will be to x86 or ARM, which it does support well (from everything I've heard).

Don't things get more complicated than that if you are expecting certain architecture features like SIMD?

I remember some comments here on HN a few months back (maybe longer) about how there isn't really an "ARM" to target, as since there's such diversity in what an ARM chip can provide that it's hard to make assumptions about what you can rely on from just "ARM". I believe it was in response to what is available to help with booting the system, but I imagine it extends into what exactly your runtime can rely on.

> I'm pretty sure that the range of platforms for which Go does cross compilation "very well" is quite small

Given that the number of popular platforms is approximately 2 (Intel and ARM), I don't see that as a huge problem.

Well, the OS and bit width matters too. {x86-32, x86-64, 32-bit ARM, AArch64} on {Windows, Mac, Linux, Android, iOS} ends up describing a decently large set of targets.

Also, you'd be surprised how often people request minor platforms. It's enough that we regularly get people asking for a C backend because they only have a C compiler for that target (though I think a C backend ends up usually not being what those people actually want).

Hm... I probably don't know enough about compilers, but why does Windows/Mac/... matter for a compiler (I see why it would matter for the standard library)? AFAIK, the main differences between these platforms are calling conventions (and possibly exception mechanisms), which LLVM should abstract away.

You're missing at least (a) structure padding/alignment; (b) debug info; (c) name mangling. LLVM abstracts over some of the differences but definitely not all.

In any case, just having a Rust compiler isn't very useful; you need a standard library (or at least libcore) to do anything interesting with the language, and that's where most of the porting effort comes in.

Actually, for compilers, platform is typically not just hardware, but the operating system as well. Windows and Linux are night-and-day different for major platform requirements (e.g., filesystems, I/O), and even Linux and FreeBSD can be important target differences in some platform areas.

So the number of platforms is approximately {x86-32, x86-64, ARM, AArch64}×{Windows, OS X, Linux, iOS, Android} (- a few combos) ~= 17 (I think). MIPS, Sparc, and PowerPC can be useful in some scenarios, as can even x86-16 (hey, wanna write the initial startup code on x86?), and platforms like PNaCl, Emscripten, or WebAssembly are effectively their own platforms as well.

Even PowerPC can be both 32-bit and 64-bit, and has operating systems like AIX and Wii U. I'm guessing one of those ports would be a bit harder.

And PPC has big and little endian variants, to add to the matrix.

You're missing PIC, AVR and quite a few other architectures that exist in the uC space(and Rust could be a great target for).

In that case Rust has exactly the same cross compilation story. You're lowering the bar for Go but not for Rust if you're making that comparison.

This indeed would be very cool! Right now things work relatively well with the biggest pain being the acquisition of std for your target.

If std and core could be made into first-class crates, then you could get rid of the need to find a pre-built version of libstd for your target. It would just be built when needed by a project.

This is what we currently do in zinc for core via the hack here: https://github.com/hackndev/zinc/blob/master/Cargo.toml#L27. Zinc doesn't use std (for obvious reasons). Right now, targeting a raspberry pi is much harder than it should be as a result of having to having to find an appropriate cross-compiled std.

That is, I want the steps for cross-compilation to be:

1. Execute `cargo build --target=foo`.

2. There is no step 2.

It would absolutely be huge! Writing some ARM firmware in Rust wasn't as straightforward as it could be.

As someone looking to use Rust primarily on the Raspberry Pi and other embedded systems, this is a big deal.

Maybe because many of us used cross compilers across multiple programming languages?

Reply on news.ycombinator.com