Finally making a bug to keep track of what we need to do. Upstream don't provide bootstrap binaries for all of our arches but they do provide support for: mips, ppc, riscv, s390x, sparc(?), armv4, armv5. It seems like alpha/ia64/s390/m68k are out of luck though.
Package list is empty or all packages have requested keywords.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fbc82dfc0fd9213f3205747f1814737a985495f5 commit fbc82dfc0fd9213f3205747f1814737a985495f5 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-26 08:19:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-26 08:20:40 +0000 dev-python/cryptography: add 36.0.0, drop 3.4.7_p12052021 (Rust, unkeyworded) Unkeyworded while we figure out a plan to handle arches which currently do not support Rust. (We _might_ be able to handle some/all of them by building rust-bin bootstrap binaries ourselves, as Rust upstream handle some arches by giving them a lower tier of support w/o prebuilt Rust. Or we wait for the rustc + libgccjit backend. Or we wait for the GCC Rust frontend.) Bug: https://bugs.gentoo.org/769482 Bug: https://bugs.gentoo.org/827350 Bug: https://bugs.gentoo.org/769452 Signed-off-by: Sam James <sam@gentoo.org> dev-python/cryptography/Manifest | 53 ++++++---- ...p12052021.ebuild => cryptography-36.0.0.ebuild} | 107 +++++++++++---------- 2 files changed, 88 insertions(+), 72 deletions(-)
(In reply to Sam James from comment #0) > Finally making a bug to keep track of what we need to do. > > Upstream don't provide bootstrap binaries for all of our arches but they do > provide support for: > mips, ppc, riscv, s390x, sparc(?), armv4, armv5. > > It seems like alpha/ia64/s390/m68k are out of luck though. Updarted list: I am not including: - musl in this because that's a confusing factor and sorting out musl support shouldn't be too bad for each arch if it's otherwise supported - arches we already support somehow Upstream provides binaries (see https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-2-with-host-tools) for: - s390x (NOT s390) - mips (mips, mips64, mips64el, mipsel - I don't know which ABIs we support) Supported with no pre-built binaries (see https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-2): - arm (armv5te, armv7 soft float?) - x86 (i586) - sparc (sparc64) Not-really-supported-but-might-work, with no pre-built binaries (see https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3): - arm (armv4t) - x86 (i386) - ppc (spe, a niche variant) - riscv (see the page) - sparc (sparc32) - m68k --- Summary: We need to package *upstream* binaries for: - s390x - mips We may need to build binaries for: - arm: armv5te, armv4t, armv7 soft float - x86: i586, i386 - sparc: sparc32, sparc64 - ppc: spe - riscv: (all?) Totally hosed platforms: - alpha - ia64 - hppa
(In reply to Sam James from comment #8) > Totally hosed platforms: > - alpha > - ia64 > - hppa s390 (NOT s390x) is hosed too.
(In reply to Sam James from comment #8) > > We need to package *upstream* binaries for: > - s390x > - mips - some riscv > > We may need to build binaries for: > - arm: armv5te, armv4t, armv7 soft float > - x86: i586, i386 > - sparc: sparc32, sparc64 > - ppc: spe > - riscv: (all?) - some mips?
s390x and mips should work, just need to add keywords. for mips we can support mips-unknown-linux-gnu mipsel-unknown-linux-gnu mips64-unknown-linux-gnuabi64 and s390x-unknown-linux-gnu I have neither of those machines so I can't test. but testing rust-bin should be easy.
(In reply to Sam James from comment #8) > (In reply to Sam James from comment #0) > > Finally making a bug to keep track of what we need to do. > > > > Upstream don't provide bootstrap binaries for all of our arches but they do > > provide support for: > > mips, ppc, riscv, s390x, sparc(?), armv4, armv5. > > > > It seems like alpha/ia64/s390/m68k are out of luck though. > > Updarted list: > > I am not including: > - musl in this because that's a confusing factor and sorting out musl > support shouldn't be too bad for each arch if it's otherwise supported > - arches we already support somehow > > Upstream provides binaries (see > https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-2-with- > host-tools) for: > - s390x (NOT s390) > - mips (mips, mips64, mips64el, mipsel - I don't know which ABIs we support) [snip] It looks like rust upstream does prebuilds for MIPS big- and little-endian, but only for the pure 32-bit ABI (o32, mips[el]-unknown-linux-gnu) and pure 64-bit ABI (n64, mips64[el]-unknown-linux-gnuabi64). This is mildly problematic because most of the install stage targets I build are for the n32 ABI, which is a hybrid 32-bit/64-bit ABI (similar to what x32 wanted to do on x86/x64, but n32 is older than x32 -- developed in the mid 1990's for SGI's IRIX). The Linux CHOST target is mips64-unknown-linux-gnuabin32. The only two stage targets that would be usable with these prebuilds would be the glibc_o32-mips2 target for the 32-bit big-endian build and the glibc_multilib-mips3 target for the 64-bit big-endian build. We do not have a pure n64 ABI target, and likely never will (there's no viable use case for one). I also do not have any working little-endian MIPS hardware (my Cobalt appliances are far too underpowered to be usable -- max RAM is 256MB). It is somewhat puzzling that the rust devs left out or ignored n32 ABI. It is a bit hard to wrap your head around at first, but if you're going to run 64-bit MIPS, you want to use the n32 ABI.
for involved. rust-1.58.1 now includes USE=dist it will install xz tarballs to /usr/lib/rust/1.58.1/dist/ those are exactly same format rust-bin uses. and those tarballs can be used as distfiles for rust-bin on some arches we don't normally have rust on. all we have to do is to somehow get working rust compiler, maybe outside of portage, and build gentoo's dev-lang/rust at least once, grab dist tarballs and produce rust-bin for that arch.
(In reply to Georgy Yakovlev from comment #13) > for involved. > > rust-1.58.1 now includes USE=dist > > it will install xz tarballs to /usr/lib/rust/1.58.1/dist/ > > those are exactly same format rust-bin uses. > and those tarballs can be used as distfiles for rust-bin on some arches we > don't normally have rust on. > > all we have to do is to somehow get working rust compiler, maybe outside of > portage, and build gentoo's dev-lang/rust at least once, grab dist tarballs > and produce rust-bin for that arch. Can someone with better contacts with rust upstream ping them on whether they have looked at the MIPS N32 ABI before? The binary builds they provide won't work for the targets I usually focus on, which are all primarily N32. I have a single O32 target that will probably work, and no pure N64 targets, just the multilib, but even that one is majority N32 with just enough libs for mixed O32/N64. If they've tried N32 before and ran into problems, it'd be good to know what those problems are and if they are actively working to resolve them.
I've written up the steps for bootstrapping via cross at https://wiki.gentoo.org/wiki/User:Sam/Drafts/Bootstrapping_Rust_cross. It's not perfect and doesn't yet(?) try to minimise use of external binaries / prefer system ones. I'm guessing that's possible but I really just wanted something working as I wasn't sure if it would even work as I went.
Dropping sparc from this bug.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0fd31bae8abc127916008c78ecb5a2cf29661075 commit 0fd31bae8abc127916008c78ecb5a2cf29661075 Author: matoro <matoro@users.noreply.github.com> AuthorDate: 2022-09-15 19:10:08 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-23 00:05:22 +0000 virtual/rust: keyword 1.63.0 for ~mips Bug: https://bugs.gentoo.org/769452 Closes: https://github.com/gentoo/gentoo/pull/27259 Signed-off-by: Sam James <sam@gentoo.org> virtual/rust/rust-1.63.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mips done
