[Bug 1233359] New: clang-tools of llvm19 break building Firefox ESR on Tumbleweed
https://bugzilla.suse.com/show_bug.cgi?id=1233359 Bug ID: 1233359 Summary: clang-tools of llvm19 break building Firefox ESR on Tumbleweed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs@suse.de Reporter: manfred.h@gmx.net QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- Mozilla ESR's .spec file BuildRequires: clang18-devel. Building it fails since TW snapshot 20241108 which introduced llvm19. Looking at the build log (see attached file "Make-TW.log") shows that some "clang version 19.1.3" is used, while it used to be "clang version 18.1.8" before that snapshot (see attached Make-mine.log". This appears to be caused by the clang-tools package which was version 18.1.8, but is version 19.1.3 now. Full logs can be found at <https://build.opensuse.org/public/build/home:manfred-h:mozilla:esr:TW/openSUSE_Tumbleweed/x86_64/firefox128esr/_log> <https://build.opensuse.org/public/build/home:manfred-h:mozilla:esr/openSUSE_... We are currently in the process to prepare a new package for Tumbleweed called "firefox-esr" which tracks the official "Mozilla Firefox ESR 128" sources to allow users to remain on a more conservative package but still get security updates and fixes. I "solved" the clang-tools issue for myself by branching the llvm18 package into one of my home:manfred-h repos, adding Macros: %product_libs_llvm_ver 18 :Macros to its project configuration and building my own llvm18 package. This one now provides clang-tools-18.1.8-8.1.x86_64.rpm and firefox-esr can be built again. When our firefox-esr package gets accepted for openSUSE:Factory/Tumbleweed, there won't be a versioned clang18-tools package however. Can we get such a versioned clangNN-tools package by default, please? If not, why not? Thx. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1233359 https://bugzilla.suse.com/show_bug.cgi?id=1233359#c1 --- Comment #1 from Manfred Hollstein <manfred.h@gmx.net> --- Created attachment 878565 --> https://bugzilla.suse.com/attachment.cgi?id=878565&action=edit Output from "grep 'clang version'" of https://build.opensuse.org/public/build/home:manfred-h:mozilla:esr:TW/openSU... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1233359 https://bugzilla.suse.com/show_bug.cgi?id=1233359#c2 Manfred Hollstein <manfred.h@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manfred.h@gmx.net --- Comment #2 from Manfred Hollstein <manfred.h@gmx.net> --- Created attachment 878566 --> https://bugzilla.suse.com/attachment.cgi?id=878566&action=edit Output from "grep 'clang version'" of https://build.opensuse.org/public/build/home:manfred-h:mozilla:esr/openSUSE_... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1233359 Manfred Hollstein <manfred.h@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wolfgang@rosenauer.org -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1233359 Manfred Hollstein <manfred.h@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.sirringhaus@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1233359 https://bugzilla.suse.com/show_bug.cgi?id=1233359#c3 Aaron Puchert <aaronpuchert@alice-dsl.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aaronpuchert@alice-dsl.net --- Comment #3 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Manfred Hollstein from comment #0)
Mozilla ESR's .spec file BuildRequires: clang18-devel. Building it fails since TW snapshot 20241108 which introduced llvm19. Looking at the build log (see attached file "Make-TW.log") shows that some "clang version 19.1.3" is used, while it used to be "clang version 18.1.8" before that snapshot (see attached Make-mine.log". This appears to be caused by the clang-tools package which was version 18.1.8, but is version 19.1.3 now. Full logs can be found at
I don't think so, clang-tools only requires /usr/bin/clang, which is also provided by clang18. It's more likely related to libclang.so.13, which always uses the latest Clang version. It emits this error: error: incomplete type 'EnumSet<T, Serialized>' where a complete type is required Maybe this error can be fixed in the Firefox? It's likely the consequence of some defect report, see the change log [1].
Can we get such a versioned clangNN-tools package by default, please? If not, why not? Thx.
The package consists of all the files that cannot coexist in multiple versions. When it comes to libclangN, I think we should stick to shipping the latest version only because they are API/ABI-compatible and it allows applications to profit from updates without rebuilds. It will in some cases cause breakage, but that should be limited to defects that should probably be addressed anyway. Compilers don't do backwards-incompatible changes without good reasons. [1] https://releases.llvm.org/19.1.0/tools/clang/docs/ReleaseNotes.html -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1233359 https://bugzilla.suse.com/show_bug.cgi?id=1233359#c4 Aaron Puchert <aaronpuchert@alice-dsl.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rguenther@suse.com --- Comment #4 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- For reference, the full error is this: [...]/obj/dist/include/mozilla/EnumSet.h:339:38: error: incomplete type 'EnumSet<T, Serialized>' where a complete type is required [...]/obj/dist/include/mozilla/EnumSet.h:30:7: note: definition of 'EnumSet<T, Serialized>' is not complete until the closing '}' The path doesn't match, but it might be in https://hg.mozilla.org/mozilla-central/file/FIREFOX_BETA_128_BASE/mfbt/EnumS...: static constexpr size_t MaxBits() { if constexpr (std::is_unsigned_v<Serialized>) { return sizeof(Serialized) * 8; } else { return Serialized::Size(); } } static constexpr size_t kMaxBits = MaxBits(); // ^ EnumSet.h:339:38 with the note on "class EnumSet". The note is correct, but I'm not sure why calling a static member function requires a complete type. It might be related to "constexpr", because you cannot allow cyclic dependencies in constexpr evaluation. (Imagine if MaxBits referred to kMaxBits in its body.) Since member function bodies are parsed when the class is complete, the body of MaxBits might not be available yet when we're evaluating the initializer. The solution is easy: move MaxBits out of the class. (Of course it needs Serialized as template parameter.) Then it should compile. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1233359 https://bugzilla.suse.com/show_bug.cgi?id=1233359#c6 Manfred Hollstein <manfred.h@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Manfred Hollstein <manfred.h@gmx.net> --- Hi Aaron and Richard, thanks for your help. Of course, the solution is even easier... We had an old patch lingering around which got introduced for firefox102esr. This is the patch: Index: firefox-102.4.0/mfbt/EnumSet.h =================================================================== --- firefox-102.4.0.orig/mfbt/EnumSet.h +++ firefox-102.4.0/mfbt/EnumSet.h @@ -326,7 +326,7 @@ class EnumSet { } } - static constexpr size_t kMaxBits = MaxBits(); + static constexpr size_t kMaxBits = EnumSet().MaxBits(); Serialized mBitField; Removing this patch leaves the "MaxBits()" call unqualified which allows proper compilation with both my llvm18 and with llvm19 from Factory. I'm closing this report now! -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com