Hi,
is there practical reason why cross-compiling to a know target involves building a whole compiler? Shouldn’t it be possible to just build the libraries with an installed version of the compiler? Does the build system of rust-lang/rust support that in any way?
If yes, how would that be done? I’m trying to crosscompile by hand to netbsd as discribed in[1], but the process seems very brittle.
[1] http://www.hashmismatch.net/2015/05/18/pragmatic-bare-metal-rust.html
It’s mostly because we haven’t built up the infrastructure yet, though there are plans in motion. Right now we’re uploading binary versions of the standard libraries for several cross-targets, but the tooling isn’t able to install them yet. This multirust PR will add the ability to install some cross-std targets. In the future we have plans to rewrite multirust in Rust and teach that tool to also acquire the cross-platform NDK’s (like the rumprun toolchain).
Just today I was experimenting with Rust on rumprun (and discovered it’s broken). Also experimenting with adding emscripten support to Rust (which looks pretty simple). Right now rumprun std is not something we’re producing nightly, but I hope to soon.
I’m thinking in the next quarter the cross-compile experience will get significantly better.
Just a quick braindump. Sorry things aren’t so hot right now.
Ah, I think I understand your suggestion of ‘just build the libraries’ now to mean ‘build std on demand’. It’s tantalizingly possible, but in practice quite hard, and as I described above what we’re pursuing now is for the project to make std available in binary form for as many targets as possible.
The main reason it’s difficult is just that building std is (I believe) more difficult than building typical Rust programs, since it has some points of close integration with the plattform (like memory management, unwinding, backtraces). It also has a complex and custom build system, and contains unstable code that can’t presently be built with the stable compiler.
Building std requires a native cross-toolchain (such as the android ndk) to do the cross-compile. This is true for building any cross-compiled Rust code though. The hardest part of making cross compilation easy on Rust will be making these bits easily available.
I think eventually we’ll probably get to a place where cargo can easily rebuild std.
Well, I do understand that, but having the cross-toolchain available is necessary in any case.
I just don’t understand why “.configure --target ‘x-y-z’ --use-rust=/usr/local/bin/rustc; make std” is not existing, even if - to my understanding - it should be possible, which would make development of tooling for those toolchains much easier.
Unfortunately that needs some extra effort to “just work”. The standard library uses unstable features in the compiler, which poses two problems:
I definitely agree with the sentiment that it’d be nice if this was easy, but there are indeed some reasons why it’s a little hard today!
I am aware of both, but the first is a check that can be trivially implemented (and is done by hand by everyone trying to do so), and the second is something that is currently not that much of an issue, as people doing cross-compilation are working on nightly anyways. The problem is currently not “a little hard”, but mostly incredibly time-consuming, even if you have the necessary compiler at hand!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.