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