Re: llvm update to 20.1.8

[Thomas Klausner <wiz%netbsd.org@localhost>]

Hi!

Another update: adam fixed mlir, unmasking flang.

Now only lldb and flang are broken.

https://www.netbsd.org/~wiz/llvm-20.7.diff

(This llvm version is needed for updating rust, btw.)

Comments?
 Thomas

On Sat, Feb 21, 2026 at 12:01:05PM +0100, Thomas Klausner wrote:
> Hi!
> 
> I've updated the diff - ccls was updated in the meantime, and I've
> reduced the differences to the current pkgsrc state and restored one
> Solaris patch.
> 
> https://www.netbsd.org/~wiz/llvm-20.6.diff
> 
> Testing welcome.
> 
> Thanks,
>  Thomas
> 
> 
> On Mon, Feb 16, 2026 at 01:41:20AM +0100, Thomas Klausner wrote:
> > Hi!
> > 
> > I've worked on an update for llvm & all related packages to 20.1.8, as
> > well as some other packages that needed build fixes for the new llvm
> > version. The update is based on adam's work up to commit
> > 1f701ceffc8429f61d994f9cb829b4c07e4f4bf4 in wip (wip is already
> > tracking llvm 21) with additional fixes.
> > 
> > This llvm update allow upgrading zig (included) and rust (not
> > included) to newer versions.
> > 
> > I've tested bulk-test-llvm (including rust, zig, firefox and
> > thunderbird) on NetBSD 11.99.5/x86_64, and it built except for two
> > packages:
> > 
> > mlir:
> > 
> > fails, not finding libMLIR.* - reported upstream at
> > https://github.com/llvm/llvm-project/issues/181584
> > 
> > lldb:
> > 
> > fails in the NetBSD specific code - reported upstream at
> > https://github.com/llvm/llvm-project/issues/181586
> > 
> > lldb is a leaf packages (except for the bulk test package), mlir is
> > used by flang.
> > 
> > I'd like to go ahead with the update anyway so we can get newer rust &
> > zig.
> > 
> > The update is here[1]:
> > 
> > https://www.netbsd.org/~wiz/llvm-20.5.diff
> > 
> > Please review & test, and if you have ideas for fixes for the two
> > problems listed above, I'd appreciate it.
> > 
> > Thanks,
> >  Thomas
> > 
> > 
> > [1] The update is not in wip because wip is not well suited for this
> > use case (you could install the packages from there, but the
> > dependencies in the standard pkgsrc tree would have to be manually
> > changed to point to wip for bulk builds to succeed) - pkgsrc branches
> > would be better.