Comment # 21 on bug 1192067 from
(In reply to William Brown from comment #20)
> IIRC it's related to LLVM being part of the graphics pipeline somewhere but
> I don't recall all the details ... 
Usually Mesa wants a newer LLVM and that's how it ends up in SLE. But I'd ship
the newest version at the time of release in Leap even if it wasn't for Mesa.

> > Though it could lead to issues with the installation medium, perhaps that's
> > why we want to limit the versions in Leap. In Tumbleweed we mostly switch
> > everything to newer versions when they become available, but on SLE packages
> > aren't rebuild when dependencies update, so we might need multiple libLLVMs
> > on the DVD.
> 
> Again, I think here it's up to what SLE does given how llvm/rust are managed
> there. I have a hand in Rust inside SUSE, but I'm not involved in the LLVM
> side. Regardless, I think keeping llvm lock stepped to rust versions will be
> important from now, and the question is how we go about that with SLE with
> regard to bundling LLVM or not. But that's something for me to chase up :) 
I don't have any concerns with that, given that Rust is usually quick to catch
up. On the contrary, it makes it easier for me to bring newer LLVMs into TW.

As for SLE/Leap, let's see how we handle that.

I see two possible reasons why things didn't work out this time:

* Normally Rust doesn't compile with newer LLVMs because of interface changes,
but this time that hasn't been the case. The relevant PR
https://github.com/rust-lang/rust/pull/87570 was not in 1.55, yet we didn't
have any compiler errors. With previous LLVM updates I saw that Rust didn't
build and then I either ported back the "Upgrade to LLVM XX" PR or we waited
for the next release to come out. This time we didn't see any errors, so we
didn't do anything.

* The new pass manager is now the "default". Rust switched in
https://github.com/rust-lang/rust/pull/88243, also in 1.56. The old PM is still
maintained, but probably not as well-tested anymore since Clang made the
switch.


You are receiving this mail because: