rust: cross build (&template cleanup)

[Cogitri]

Continuation of #3101. @Gottox currently seems to be very busy,
so I offered to get this working in #xbps earlier. Currently
building x86_64 -> aarch64, which doesn't work as of now, but early progresses somewhat further than before. However,
there's still stuff to be done:

• Test if other arches actually build
• Test if the cross built binaries actually work
• Adjust build-style/cargo.sh: add [ci skip] #2837 to work if cross (should be easy enough)

[maxice8]

needs to add [ci skip]

[Cogitri]

Currently tries to link against the host's LLVM: https://gist.github.com/0d9460d77cd0ce964b53f9526c6f47fe

[jnbr]

Here is a workaround for linking against host llvm:

--- rustc-1.28.0-src/src/librustc_llvm/build.rs.orig    2018-10-01 04:00:15.481334857 +0200
+++ rustc-1.28.0-src/src/librustc_llvm/build.rs 2018-10-01 04:01:15.145790417 +0200
@@ -227,8 +227,8 @@
             println!("cargo:rustc-link-search=native={}", &lib[9..]);
         } else if is_crossed {
             if lib.starts_with("-L") {
-                println!("cargo:rustc-link-search=native={}",
-                         lib[2..].replace(&host, &target));
+                println!("cargo:rustc-link-search=native={}{}",
+                         env::var("XBPS_CROSS_BASE").unwrap(), &lib[2..]);
             }
         } else if lib.starts_with("-l") {
             println!("cargo:rustc-link-lib={}", &lib[2..]);

The original replace() doesn't work because the vlaue of host doesn't appear in the output of llvm-config --link-shared --ldflags.

[Cogitri]

Thanks, that worked. Now it tries to run the just cross compiled stage0 compiler though (which obviously doesn't work due to it being compiled for a different arch). Will look into it.

[Gottox]

I had the approach to unset the cross build environment variables through stage0 and let the build system figure out which vars to set. An alternative approach that would safe build time is to skip stage0 and stage1 and directly build the final compiler. The bootstrapping is already done in the native build.

[Cogitri]

An alternative approach that would safe build time is to skip stage0 and stage1 and directly build the final compiler.

Sounds good, as we can't run any stage1 binaries during cross compilation anyway

[Gottox]

But I have no idea how to convince the build system to start with stage2.

[Cogitri]

I suppose we can do so by directly using x.py

[Cogitri]

Seems like we've mixed up build and host though, if I understand it correctly build is the machine running the build (and the arch for which the stage0 compiler is compiled for) while host and target are the triplets we want to compile for.

[Cogitri]

Alright, cross building to aarch64 works now, testing the other arches. Does someone have aarch64 hardware to test the package? Otherwise I'll setup void on my RPI 3.

[Cogitri]

Do note that bootstrapping rust on the host platform (not cross compiling) doesn't work right now, but the issue that causes it to fail is fixed in 1.28->1.29 anyway, so I don't really feel like wasting time on fixing that, I just need the 1.28 rust musl dist tarball to be uploaded my someone.

[Cogitri]

Okay, in theory we could also build the rust standard library for every target, but that seems rather cumbersome and unnecessary. For our use cases it works just fine if we only compile the standard library for the target we're building for and just using --sysroot to use the correct standard library for the target. People who want to use rust for developing and want to cross compile should most likely use rustup anyway.

[Cogitri]

Alright, rust builds for all platforms. Just adjusted the cargo build style and testing cross build for all of those packages.

[Gottox]

bootstrap musl rustc is currently compiling 👍

[Cogitri]

I will update rust to 1.29.1 after this, AFAIK firefox doesn't build with it and it makes sense to not merge all of this at once so that it's easier to see why stuff is breaking (in case it does).