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

https://bugzilla.suse.com/show_bug.cgi?id=1192067 https://bugzilla.suse.com/show_bug.cgi?id=1192067#c21 --- Comment #21 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to William Brown from comment #20) 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: You are on the CC list for the bug.