Rust isn't going away and both GNOME and GStreamer are looking seriously at it. Concretely, librsvg requires Rust to build now. I believe we should evaluate the impact of adding the core rust libraries to oe-core for 2.6. CCing Maxin as he has expressed an interest in working on this.
I can help on this as well.
The biggest question might be whether there is any way to not start by downloading a host binary from the internet. And I am not sure what other option would be available. Rust requires Rust for building, and different from Go (where an ancient version is sufficient) only the current and the previous version are supported for building. Firefox always needs recent Rust. That's why Ubuntu LTS gets Rust updated to a new major version every 2 months.
There seems to be: https://www.gnu.org/software/guix/blog/2018/bootstrapping-rust/ it looks like a >= 12 stage bootstrap proceedure that starts with a Rust compiler, called "mrustc", written in C++.
Of course we wouldn't want to run the 12 stage build every time! We could store and download the N-1'th stage as a convenience similar to how the uninative tarball is used.
(In reply to comment #4) > Of course we wouldn't want to run the 12 stage build every time! We could > store and download the N-1'th stage as a convenience similar to how the > uninative tarball is used. The recipe in meta-rust is already doing that, downloading the previous version from upstream.
Randy was talking about this recently, so passing over to him. Feel free to pass the hot potato further.
I've been rebasing the copy from meta-rust locally but I suspect that if 3.1 is going to have a chance of being a stable LTS release, we should delay rust to 3.2.
I have updated my local patch set to integrate additional commits from meta-rust but I've encountered a problem when compiling the newer versions of librsvg. The rustc compiler configuration is broken. I haven't figured out what's wrong so it's unlikely to be resolved for 3.1. See: https://github.com/meta-rust/meta-rust/issues/264
I have updated my rust work in progress in oe-core and it builds well for all qemus except two lower priority musl libc targets: $ ssh rmacleod@ala-lpggp3: $ cd /ala-lpggp31/rmacleod/src/distro/yocto/b/rust-core2 $ buildall-qemu rust-hello-world $ cat rust-hello-world-buildall.log BUILDALL-QEMU LOG FOR rust-hello-world START TIME: 2021-02-02_12:43:38 HOSTNAME: ala-lpggp3 HOST OS: Ubuntu 18.04.3 LTS HOST KERNEL: 5.4.0-62-generic =============== BUILD RESULTS: [glibc] PASS: qemuarmv5 PASS: qemumips PASS: qemux86-64 PASS: qemuarm64 PASS: qemumips64 PASS: qemuarm PASS: qemuppc PASS: qemuriscv64 PASS: qemux86 [musl] PASS: qemuarmv5 PASS: qemumips PASS: qemux86-64 PASS: qemuarm64 PASS: qemumips64 PASS: qemuarm FAIL: qemuppc FAIL: qemuriscv64 PASS: qemux86 =============== PASSED: 16 FAILED: 2 ---- I formatted the 53 patches and moved them to poky-contrib: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=rmacleod/rust-wip-2021-02-02 Next up: 1) update to rust-1.49 2) Add Ross's arm64 builder patch 3) Add the fix for rustc to some (!) recipe file: $ ./tmp-glibc/work/core2-64-oe-linux/rust-hello-world/git-r0/recipe-sysroot-native/usr/bin/rustc --print cfg error: Error loading host specification: Could not find specification for target "x86_64-linux" -- Fix for cmd line: $export RUST_TARGET_PATH="/.../tmp-glibc/work/core2-64-unknown-linux/librsvg/2.46.4-r0/recipe-sysroot-native/usr/lib/rustlib" $ ./tmp-glibc/work/core2-64-unknown-linux/librsvg/2.46.4-r0/recipe-sysroot-native/usr/bin/rustc --print cfg debug_assertions target_arch="x86_64" ... 4) remove all but the most recent version(s) of rust? 5) clean up patchs 6) submit to oe-core
Merged, See this commit and many others after that: https://git.openembedded.org/openembedded-core/commit/?id=3ed57578cca93ff1ba4e0bf3f25566e10659a2f9