Re: llvm packaging status

[Havard Eidnes <he%NetBSD.org@localhost>]

> is anyone working on the update of llvm to 16.x or 17.x? With 16.x we
> had prior work of myself and 1 or 2 other people.
> Did it just stagnate because of the time/size of the update? What were
> identified issues beyond what I pointed out (I think firefox and
> thunderbird failed to start?).

"Don't look at me!" :)

That said, the embedded llvm inside rust has already been
upgraded to 17.x:

1.75.0 (upcoming) contains llvm 17.0.6
1.74.1 contains llvm 17.0.4
1.73.0 contains llvm 17.0.2
1.72.1 contains llvm 16.0.5
1.71.1 contains llvm 16.0.5

That has not been without its own set of issues, since all the
bootstrap kits we build for NetBSD are cross-built and are all
using the rust-embedded LLVM:


1) codegen issues for 32-bit powerpc:

There were issues building 1.74.0 with the bootstrap bits from
1.73.0.  I reported this upstream (rust), ref.

https://github.com/rust-lang/rust/issues/118099

Rebuilding the powerpc 1.73.0 bootstrap bits using an external
LLVM 15.0.7 (what I had laying around as installed bits at the
time...) made the build of 1.74.0 with its own embedded LLVM
succeed according to what I said in that issue, so even though I
had picked up a workaround for another powerpc codegen issue,
ref.

https://github.com/rust-lang/rust/issues/116845

that appears to not been the only problem with the embedded
version of LLVM in 1.73.0.  This problem *may* have been fixed
with the LLVM embedded in 1.74.1.  I need to double-check if I
can manage to natively build 1.75.0 using the cross-built
bootstrap kit for NetBSD powerpc this time around -- I have a
1.75.0 rust package in preparation for pkgsrc-wip.


2) codegen issue for 32-bit mips(el):

It appears that all rust versions with llvm >= 17 (with the
caveat that I've not yet tested 1.75.0) fails to generate correct
code for this platform; I get an "internal compiler error" when
trying to build the cbindgen package with any of the newer
rust-bin versions, ref.

https://github.com/rust-lang/rust/issues/118978

I'm slowly getting into a position where I could possibly
cross-build for this platform with an external older llvm, but
getting there requires a "native" build of cmake and llvm, and
that's taking it's own sweet time, and there's no guarantee that
this will succeed.  Testing 1.75.0 cross-built binary bits will
be done first.


So ... not sure how much we should push to get 32-bit mips fixed
before bumping our own llvm.  32-bit mips(el) is sort of a
"fringe platform", so it's not a given.  If we bump, we should
use one of the newer 17.x LLVMs so that we don't get the 32-bit
powerpc codegen issue in our LLVM.


Regards,

- Håvard