Summary: | dev-lang/rust: support system-bootstrap in a sysroot | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | David Michael <fedora.dm0> |
Component: | Current packages | Assignee: | Gentoo Rust Project <rust> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | johannes.geiss, navi, randy, rust |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | cross.patch |
Description
David Michael
2020-07-08 15:35:25 UTC
that's good thing to support and I wanted to move some build deps to BDEPEND anyway. Created attachment 648974 [details, diff] cross.patch Here is a patch I used for cross-compiling. Some notes: - It includes the fix for bug #732222 to fix a bad curl cross-compiling environment. - It sets "build" to the native triplet to fix using cross-tools on native objects. - It writes dummy CFLAGS for the native triplet to override defaulting to passing cross-compiler CFLAGS to the native compiler. - The ranlib addition isn't necessary; I just left that there. It needs this environment when running emerge: - I_KNOW_WHAT_I_AM_DOING_CROSS=yes - LLVM_TARGETS=X86 - PKG_CONFIG_SYSROOT_DIR=/usr/armv5tel-gentoo-linux-gnueabi - RUST_CROSS_TARGETS=X86:x86_64-unknown-linux-gnu:x86_64-pc-linux-gnu - USE='system-bootstrap -system-llvm' Don't use system-llvm since the build system will try to execute cross-compiled binaries for it. The LLVM target is needed to compile LLVM compatible with the build system. The cross-target definition for the native system isn't really needed; it might just need to define the linker for that Rust target, but the cross-target environment variable defines that easily. (It should probably hard-code that configuration instead when $CBUILD != $CHOST so that's not needed.) (I forgot to note that the pkg-config sysroot setting is required for it to use the cross-compiled libgit2 version instead of trying to use the native one.) Might as well note this for completeness, too, since I pasted the sysroot definition for armv5te... This change is required for cross-compiling to armv5te with at least GCC 9 because of https://github.com/rust-lang/rust/issues/48625 . --- a/vendor/compiler_builtins/build.rs +++ b/vendor/compiler_builtins/build.rs @@ -69,7 +69,6 @@ // Only emit the ARM Linux atomic emulation on pre-ARMv6 architectures. if llvm_target[0] == "armv4t" || llvm_target[0] == "armv5te" { - println!("cargo:rustc-cfg=kernel_user_helpers") } } The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=75a4d1ee6422c5e2d3984e1e7c51e65dcce66c96 commit 75a4d1ee6422c5e2d3984e1e7c51e65dcce66c96 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-07-17 00:39:23 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-07-17 06:35:02 +0000 dev-lang/rust: bump to 1.45.0 move a lot of deps to BDEPEND Bug: https://bugs.gentoo.org/703744 Bug: https://bugs.gentoo.org/683420 Bug: https://bugs.gentoo.org/731764 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-lang/rust/Manifest | 15 ++ dev-lang/rust/rust-1.45.0.ebuild | 503 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 518 insertions(+) It looks like this can be closed, unless you want to use it to track support for cross-compiling the compiler. (The bug should probably be renamed in that case.) I have no need for cross-compiling the compiler anymore since Gentoo will not allow non-upstream bootstrap binaries, so I'm not going to pursue it further. I have equipment for building upstream-like dist tarballs, but just need automation (docker or similar) and I NEED this to solve rust musl problem. so basically if a docker setup which can take couple of local patches and emit upstream-like dist tarballs, I can try bootstrapping a bit more arches, but will strictly keep using upstream tarballs which they already ship. I will research this topic as time permits, but any pointers will be helpful. Hadn't had time to properly dig this. I bet upstream has some container-like setup we can fork and re-use for lesser arches + local patches. I have not looked into how to produce upstream binaries, only Gentoo binpkgs. For that, automation should probably take four options: Rust version, LLVM_TARGETS architecture, CHOST triplet, and Rust target. The process would be: - Enter a stage3 container - Run emerge-webrsync - Apply the Rust ebuild patch and update manifest - Write the native environment vars LLVM_TARGETS, RUST_CROSS_TARGETS, etc. - Run emerge to update the stage3 and install crossdev, virtual/rust, and rust-bin (or take the extra time to compile dev-lang/rust ... or start campaigning to get Rust built into the stage3 images) - Run crossdev to build cross-compilers - Update $SYSROOT/etc/portage with the target environment and any patches - Run cross-emerge to install dev-lang/rust and create a binpkg That's what my own automation does anyway. It's for a much more generalized build environment, though, so it will probably be easier to write a simple procedure from scratch rather than try to make sense of my scripts. I've started using docker only recently myself and have this setup https://github.com/gyakovlev/gendo/ it's a bit dumb and pre-alpha but it works. beauty of it is you can do DOCKER_HOST="ssh://arm-host-with-docker" make rust and it will emit arm binpkgs to _local_ directory after completion. it does not always succeed and needs a lot of work, so just proof of concept for now. another great thing about rust bootstrap is that `./x.py dist` creates dist tarballs for all components, so ebuild can emit/expose those with some MAINTAINER_ONLY variable. I'll be researching this subject more at time permits, but that's all I have for now. |