[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: rust 1.51.0 for 32-bit earmv7hf/9.0
>> it turns out that rust version 1.51.0 can't be natively built on
>> a true 32-bit earmv7hf system -- the build of rustc_middle blows
>> up by exhausting the available data segment size. There is hope
>> that rust 1.52.0 is going to improve in this respect, but
>> meanwhile I've built the 32-bit version in a 32-bit chroot on an
>> aarch64 NetBSD system.
> Thanks. To me this is a clue that we are going to have to depart from
> rust and rust-bin to also having a third rust-nbin or soemthing, to
> install binaries that TNF peoople have built, instead of
> rustproject-built binaries in rust-bin.
I have a draft modification to the rust-bin package in the works.
It looks like the "binary rust distributions" provided by
upstream is essentially the same as the binary bootstrap kits I
build for the ports I do this for.
The title of the package would for those ports change from
Safe, concurrent, practical language (official binaries)
Safe, concurrent, practical language (NetBSD binaries)
With that said, installing the rust binary distribution still
takes a lot of time (particularly the rust-docs component, I've
not delved into why yet, but it's a bash shell script which does
the work and accumulates the CPU time...), especially compared to
installing a ready-to-go binary package.
If this (the rust-bin modification) is deemed useful, I'll go
ahead and commit what I have (and, yes, I'll let pkglint chew on
it before I do :)
Security-wise this isn't too different from doing your own "from
source" rust build on any of the affected platforms, because in
that case you would already be using the binary bootstrap kit
that I've built as the "previous rust version"...
There appears to be work afoot to get "mrustc" (apparently
written in C++) suitable for bootstrapping a full rust build
without having to resort to a binary bootstrap, but we're not
quite there yet.
Main Index |
Thread Index |