[Bug 1192067] Rust1.55 miscompiles Firefox on Tumbleweed
https://bugzilla.suse.com/show_bug.cgi?id=1192067 https://bugzilla.suse.com/show_bug.cgi?id=1192067#c20 --- Comment #20 from William Brown <william.brown@suse.com> ---
1. llvm is very slow to compile, so when compiling rustc / cargo is good to use the llvm from the system to gain some speed.
Correct - but we can speed it up with the use of sccache in OBS, [...] It's not just that, to be fair, but also about unbundling.
I'm aware :)
The reason we have to build llvm in leap15.3 is just because llvm13 isn't available there yet, else we could use the distro llvm. I can't remember the exact details about llvm and out-of-band updates in 15.3 but if 13 becomes available we can swap to that potentially. That's not up to me���someone at SUSE would have to do that. So far we've only added new LLVMs with new Leap releases, but I don't see why it has to be that way. We could certainly add newer versions between releases as well.
IIRC it's related to LLVM being part of the graphics pipeline somewhere but I don't recall all the details ...
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 :)
we could do the checks just on package submit time instead as an option, but then we'd only be testing on x86_64 (for now, I intend to get aarch64 hardware soon). In Python packages there is often some kind of multibuild setup that runs the tests separately from the actual package. Perhaps that could work?
There is also a way to specify in OBS to run checks vs not so I think that's an option I need to look into. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com