tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Rust and Q-branching
>> PKG_OPTIONS.rust+= rust-llvm
>>
>> or make it the global default?
>
> Please no. On Linux, I have my rusts using system LLVM, or pkgsrc rust
> using pkgsrc LLVM (might switch to a provided LLVM just like GCC at
> some point). As long as rust seems to happily support external LLVM
> with some minimal version, I don't see encouraging vendoring of that
> one as a good move. Build times are insane as it is now already.
>
> At least on the platforms where it will be made default, there should
> be clear reasons and not some hazy memory;-)
Alrighty, let me clear some of that haze...
At least in my case, on NetBSD/macppc 8.0, using a bulk build,
without the rust-llvm option the install phase fails in a
somewhat mysterious fashion with
Compiling idna v0.2.2
Compiling petgraph v0.5.1
Compiling crossbeam-channel v0.5.0
Compiling crossbeam-epoch v0.9.3
error[E0463]: can't find crate for `std`
error: aborting due to previous error
ref.
http://golden-delicious.urc.uninett.no/reports/2021Q2/20210703.2000/rust-1.52.1nb4/install.log
Adding the above option to /etc/mk.conf in the chroot and
re-doing the bulk build produced a working 'rust' on that
platform. However, the turn-around for such a endavour is
cumbersome to say the least -- the re-build round just finished a
few days ago, and the result is currently uploading.
The error report for i386 on pkgsrc-2021Q2 is in gnats as
PR#56304, and turns out to have another root cause, now fixed.
So ... install a hack only for NetBSD/powerpc? ("Who else than me
is as mad to do that build?" :)
Regards,
- Håvard
Home |
Main Index |
Thread Index |
Old Index