[Bug 1210176] New: LLVM16 breaks Thunderbird 102 build
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176 Bug ID: 1210176 Summary: LLVM16 breaks Thunderbird 102 build Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs@suse.de Reporter: wolfgang@rosenauer.org QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Since LLVM16 landed on Tumbleweed Thunderbird fails to build. https://build.opensuse.org/package/live_build_log/mozilla:Factory/MozillaThu... As long as we don't find a solution to make TB compile again (which we might not be able to w/o upstream) there are no TB updates possible anymore in Tumbleweed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176
Wolfgang Rosenauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176
Christophe Marin
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176
Frank Kr�ger
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176#c1
Aaron Puchert
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176#c2
--- Comment #2 from Wolfgang Rosenauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176#c3
--- Comment #3 from Wolfgang Rosenauer
So it's in some Rust code. But according to the log we're still using rust1.67, which should be using LLVM 15, not 16. [1]
Typically for Thunderbird (because it's somewhat ESR from upstream) we are not using the latest and greatest since that turned out to be very risky and often fails because the 102 codebase as of today is not tested with latest rust/llvm. So we try to use what is outlined here: https://firefox-source-docs.mozilla.org/writing-rust-code/update-policy.html which would require rust 1.60. To not block Tumbleweed with very old versions I increased to 1.67 after I was being asked by the release team to try. So much about the context why we we are selecting certain versions which would work from rust perspective BUT apparently when it comes to the combination rust/llvm this is not possible (see previous comment). Is there anything we can do about that? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176#c4
Manfred Hollstein
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176#c5
--- Comment #5 from Wolfgang Rosenauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176#c6
--- Comment #6 from Aaron Puchert
Trying to build using an older llvm version is something which has been done but still failed since llvm16 is pulled in no matter and is being used. I think it was a dependency that something requires clang-tools and clang-tools requires llvm16.
That's true, but: * It shouldn't draw in llvm16-devel or clang16-devel, and it seems like libclang is the relevant package here. (Unless they are parsing the output of clang, which sounds adventurous.) * You can still use the versioned executables, i.e. clang-15 instead of clang, either by setting CXX or by patching the build. Please note that you need to require llvm15-libclang13, otherwise it will use libclang13 = 16.0.0, which will behave like Clang 16. Just requiring llvm15-devel is not enough.
fvogt pointed me to this patch: https://github.com/rust-lang/rust-bindgen/pull/2319
That looks about right, but maybe it doesn't apply clean logically. (In reply to Wolfgang Rosenauer from comment #3)
So much about the context why we we are selecting certain versions which would work from rust perspective BUT apparently when it comes to the combination rust/llvm this is not possible (see previous comment). Is there anything we can do about that?
As far as I know, the latest Rust versions have always been pinned to the LLVM version that Rust upstream uses for their builds. Also, I don't think Rust/LLVM is the problem here, it doesn't look like a miscompilation to me. It's that libclang spits out identifiers for anonymous types that previously were empty. (In reply to Manfred Hollstein from comment #4)
In principle all older llvm packages can be stripped off their -devel packages because they don't work anymore due to the missing clang-tools package with that particular version.
How do you come to that conclusion? There are multiple packages building against older {clang,llvm}X-devel versions. The binaries in clang-tools are typically not used for builds, and should be able to exist in a newer version. They're not tied to LLVM IR but pure frontend tools. If these packages didn't work, there would be little reason for us to keep maintaining older LLVM versions at all. After all, few people are interested in using an older compiler. The main use is other packages that still use the older API and haven't been migrated yet.
It would be great if clang-tools would be put into a separate package, ideally even as a versioned one. Something like
%package -n clang%{_sonum}-tools Provides: clang-tools
The package is deliberately unversioned, because multiple versions of it can not be installed in parallel, and should not be relevant for builds to be able to install an older version. It also shouldn't have anything to do with our situation. It draws in clang16, but it doesn't block clang15-devel, and if for some reason you really need to use clang15 for compilation, for example because you're going to emit LLVM IR, you can simply use the versioned executables. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176#c7
--- Comment #7 from William Brown
So it's in some Rust code. But according to the log we're still using rust1.67, which should be using LLVM 15, not 16. [1]
Rust already pins an llvm version internally. 24 %global llvm_version 15 321 BuildRequires: llvm%{llvm_version}-devel So I think in this case, the tb spec should adjust clang to clang15-devel. I'm not sure if there is a way to "propogate" this though so that when we update rust it also pairs the same clang/llvm - something like a rust-llvm package that requires on the correct llvm version. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176
http://bugzilla.opensuse.org/show_bug.cgi?id=1210176#c8
--- Comment #8 from Aaron Puchert
So I think in this case, the tb spec should adjust clang to clang15-devel.
I'm not sure if there is a way to "propogate" this though so that when we update rust it also pairs the same clang/llvm - something like a rust-llvm package that requires on the correct llvm version.
The LLVM used by Rust and the libclang used by rust-bindgen are not really connected: one is used as backend for the Rust compiler, the other as a library in rust-bindgen. It could be that Rust upstream is only testing with the same Clang version that they use for LLVM, but that doesn't help us here at runtime: the libclang.so from major LLVM versions can't coexist, unlike libLLVM.so. That's because the former has an ABI stability guarantee across major versions, and doesn't increase the SO version anymore, while the latter has no such guarantee and gets a new SO version with every major release. So you can't pin to a certain version of libclang.so at runtime. As a workaround for building Thunderbird however, it should be fine, as long as no one needs the newer libclang.so. (In reply to Aaron Puchert from comment #6)
Please note that you need to require llvm15-libclang13, otherwise it will use libclang13 = 16.0.0, which will behave like Clang 16. Just requiring llvm15-devel is not enough.
That's currently not possible, as clang15-devel requires clang15, which requires clang-tools currently coming from llvm16, which requires clang16, which requires 'libclang.so.13(LLVM_16)(64bit)' via c-index-test, which is only satisfied by libclang13 from LLVM 16. The weakest link is probably clang-tools -> clang16. The scripts are largely version-agnostic and should be able to deal with older compiler versions. I'll see if I can cut that. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com