[Bug 1221183] New: Upgrade problems with clang-cpp
https://bugzilla.suse.com/show_bug.cgi?id=1221183 Bug ID: 1221183 Summary: Upgrade problems with clang-cpp Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Upgrade Problems Assignee: screening-team-bugs@suse.de Reporter: franz.sirl-obs@lauterbach.com QA Contact: jsrain@suse.com Target Milestone: --- Found By: --- Blocker: --- Hi, during a "zypper --releasever=15.6 dup" upgrade from a fully up-to-date 15.5 installation I got the following messages: Checking for file conflicts: ...................................................................................................................................................................[error] Detected 4 file conflicts: File /usr/bin/clang-cpp from install of clang17-17.0.6-150600.1.13.x86_64 (Main Repository) conflicts with file from install of clang13-13.0.1-bp156.7.42.x86_64 (Main Repository) File /usr/bin/clang-cpp from install of clang17-17.0.6-150600.1.13.x86_64 (Main Repository) conflicts with file from package clang11-11.0.1-150300.3.6.1.x86_64 (@System) File /usr/bin/clang-cpp from install of clang17-17.0.6-150600.1.13.x86_64 (Main Repository) conflicts with file from package clang15-15.0.7-150500.4.4.1.x86_64 (@System) File /usr/bin/clang-cpp from install of clang17-17.0.6-150600.1.13.x86_64 (Main Repository) conflicts with file from package clang7-7.0.1-150100.3.22.2.x86_64 (@System) File conflicts happen when two packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content. Continue? [yes/no] (no): yes Even though this is mostly harmless, it disturbs the upgrade experience and probably can be easily fixed by backporting the clang-cpp/update-alternatives change from clang17 to the other clang versions that are part of Leap. regards, Franz -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1221183 https://bugzilla.suse.com/show_bug.cgi?id=1221183#c1 Aaron Puchert <aaronpuchert@alice-dsl.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|aaronpuchert@alice-dsl.net |rguenther@suse.com Status|NEW |CONFIRMED CC| |aaronpuchert@alice-dsl.net --- Comment #1 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- I've also noticed this. Since the package is part of SLE, I can't do the update myself. Richard, can you port back https://build.opensuse.org/request/show/1130634? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1221183 https://bugzilla.suse.com/show_bug.cgi?id=1221183#c5 --- Comment #5 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Richard Biener from comment #2)
That's then required in all clang7, clang11, clang13 and clang15? In the SP2 codestream we also seem to have llvm9 and I can't see llvm13 so that's possibly only via the OBS sle-backports repository?
Yes, llvm13 (and llvm14) is in Backports. I can take care of this.
I'll note I had issues with the Factory python3-clang conflicts/provides switching from %python3_sitearch to something else so I reverted that (but only for llvm17).
Yes, that's fine. I mostly think about Factory when packaging and don't consider compatibility issues with Leap. This is one of those cases. (In reply to Richard Biener from comment #3)
The change for llvm15 seems to be just adding to clang_binfiles? The alternatives stuff there is obfuscated by macros.
Yes, adding to clang_binfiles and removing from the file list is the equivalent change. (https://build.opensuse.org/package/rdiff/devel:tools:compiler/llvm15?linkrev=base&rev=28) Obfuscation was not the intention. The binaries were duplicated a couple of times, and since almost every major update adds and removes binaries, and I always messed something up, I decided that having the list of binaries in one place is better. That's what you find in the beginning of the spec file plus a macro %lapply that applies another macro element-wise to a list. (Admittedly, the "list apply" is a bit of black magic, and I'd like to find a better way sometime.) As a nice side effect, this reduced the spec file by a couple hundred lines. (https://build.opensuse.org/request/show/995044)
IMO the even older llvm might be better dropped on update?
Can't talk about the versions in SLE, but the versions in Backports are unfortunately still being used: $ osc whatdependson openSUSE:Backports:SLE-15-SP6 llvm13 standard x86_64 llvm13 : autofdo velociraptor velociraptor-client $ osc whatdependson openSUSE:Backports:SLE-15-SP6 llvm14 standard x86_64 llvm14 : gtkd ispc klee klee-uclibc ldc python3-pyside2 python3-pyside2:sle15_python_module tilix tvm Not sure to which extent these packages could switch to other versions. The klee maintainer has pinned to llvm14, although a wider range of versions should be supported. Maybe we can relax this. The issue with ldc in the past was bootstrapping, not sure to which extent that has been addressed. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1221183 https://bugzilla.suse.com/show_bug.cgi?id=1221183#c9 --- Comment #9 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Franz Sirl from comment #8)
This pinning might be related to the divergence of the "clang" package between SLE and openSUSE. I remember it's quite hard to build a package requiring a newer clang on OBS. IIRC that's because requirements like "clang
= 9" don't work on SLE, but work in openSUSE. So in OBS the easy way out is to pin the version.
All of these packages are in Backports, where we have an up-to-date metapackage. (https://build.opensuse.org/package/show/openSUSE:Backports:SLE-15-SP6/llvm) I checked Klee in detail a few days ago and it's actually not that easy. It takes in additional sources that correspond to the LLVM version being used, which makes it quite a bit harder to build against other supported versions.
No idea if the clang divergence is by design or an oversight.
The earlier SPs had updates for the metapackage, but there is some reason specific to how SLE is built that made it uncompelling to update it for later SPs. Richard wrote somewhere that he would like to remove it if possible. But I don't think there are a lot of LLVM users in SLE, I'm actually only aware of Mesa. (Though some BPF-related tools and Rust might use it as well. They usually want specific versions though.) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1221183 https://bugzilla.suse.com/show_bug.cgi?id=1221183#c10 --- Comment #10 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- Almost forgot: I filed requests for llvm13/14. * https://build.opensuse.org/request/show/1165716 * https://build.opensuse.org/request/show/1165718 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1221183 https://bugzilla.suse.com/show_bug.cgi?id=1221183#c11 --- Comment #11 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- Remaining conflicts in those requests should all come from SLE (https://build.opensuse.org/projects/home:repo-checker/packages/reports/files...): found conflict of clang11-11.0.1-150300.3.6.1.x86_64 with clang13-13.0.1-bp156.15.1.x86_64 /usr/bin/clang-cpp found conflict of clang11-11.0.1-150300.3.6.1.x86_64 with clang14-14.0.6-bp156.15.1.x86_64 /usr/bin/clang-cpp found conflict of clang13-13.0.1-bp156.15.1.x86_64 with clang15-15.0.7-150500.4.6.2.x86_64 /usr/bin/clang-cpp found conflict of clang13-13.0.1-bp156.15.1.x86_64 with clang5-5.0.1-8.5.1.x86_64 /usr/bin/clang-cpp found conflict of clang13-13.0.1-bp156.15.1.x86_64 with clang7-7.0.1-150100.3.22.2.x86_64 /usr/bin/clang-cpp found conflict of clang13-13.0.1-bp156.15.1.x86_64 with clang9-9.0.1-150200.3.6.1.x86_64 /usr/bin/clang-cpp found conflict of clang14-14.0.6-bp156.15.1.x86_64 with clang15-15.0.7-150500.4.6.2.x86_64 /usr/bin/clang-cpp found conflict of clang14-14.0.6-bp156.15.1.x86_64 with clang5-5.0.1-8.5.1.x86_64 /usr/bin/clang-cpp found conflict of clang14-14.0.6-bp156.15.1.x86_64 with clang7-7.0.1-150100.3.22.2.x86_64 /usr/bin/clang-cpp found conflict of clang14-14.0.6-bp156.15.1.x86_64 with clang9-9.0.1-150200.3.6.1.x86_64 /usr/bin/clang-cpp -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1221183 https://bugzilla.suse.com/show_bug.cgi?id=1221183#c14 --- Comment #14 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Aaron Puchert from comment #9)
The earlier SPs had updates for the metapackage, but there is some reason specific to how SLE is built that made it uncompelling to update it for later SPs.
Now I remember: the problem is that SLE doesn't rebuild packages unless there are updates to the sources. That's why the metapackage doesn't work in the expected way: updating the metapackage in Factory or Backports means that all packages using it are being rebuilt, but in SLE that's not the case. Packages continue to use the old LLVM version unless they get an update after the metapackage update, and then they will use the new version. In other words: using the metapackage on SLE is basically also just pinning to a specific version, but it's not hardcoded in the specfile. It depends on the build date. Because of that, we'd rather have packages in SLE make an explicit static choice, which doesn't functionally change anything, but makes it clear what is actually being used. (In reply to Richard Biener from comment #12)
There is a request to drop the llvm meta package from SP6 repositories as well (PED-7373), I hope this extends to Leap and we can instead pull the one from backports there.
Leap's metapackage should shadow the one from SLE, so I don't expect any issues in Backports when removing SLE's metapackage. (In reply to Franz Sirl from comment #13)
Well, that's a bit unfortunate for non-SUSE OBS users like me building newer/extended versions of SLE packages.
SUSE OBS users have pretty much the same issue. For example, Mesa and related packages (like libclc) also pin LLVM versions for SLE. Another example is bpftrace: # Hard-code latest LLVM for SLES, the default version is too old %if 0%{?sle_version} == 150600 %define llvm_major_version 17 %else %if 0%{?sle_version} == 150500 %define llvm_major_version 15 %else %if 0%{?sle_version} == 150400 %define llvm_major_version 11 %endif %endif %endif
To highlight the problem, for example I would like to enable libclang support for doxygen by default via a pull request (https://build.opensuse.org/repositories/home:fsirl:doxygen-libclang), but I don't want to put that maintenance burden vs SLE on the devel:tools maintainer.
Since devel:tools builds against 15.5 and 15.6, it should be easy to see breakage. And the newest LLVM version in SLE 15 SPx is basically always 2*x + 5, with the exception of SP4 where llvm13 didn't end up in SLE but only in Backports. But otherwise the release schedules have so far aligned perfectly. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1221183 https://bugzilla.suse.com/show_bug.cgi?id=1221183#c21 --- Comment #21 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Richard Biener from comment #16)
Unless llvm changed course and promised stable APIs and backward compatibility of course.
The C APIs (of LLVM and Clang) should be more or less stable, but the wider C++ APIs are not. (In reply to Franz Sirl from comment #19)
Wait? 2 different libclang-cpp and 2 different libLLVM will be loaded?
That can happen and shouldn't be an issue. Both libclang-cpp and libLLVM have versioned symbols and should be able to coexist in different versions in the same process, unless I'm missing something. (In reply to Franz Sirl from comment #20)
The specific problem is the global object clang::format::FormatTokenLexer::CSharpAttributeTargets from libclang-cpp has global constructors/destructors. The object seemingly is merged by the shared loader when 2 libclang-cpp with different versions are loaded.
That would surprise me. I think that copy relocations allow the linking application to interpose the library variable with their own copy, but this should still be subject to symbol versioning. At least I'd hope so.
the constructors/destructors are NOT merged, meaning that 2 constructors are run for the same object on library startup and 2 destructors are run on library shutdown.
That would be expected, the constructors and destructors are not visible to the linker as symbols, but simply as anonymous entries in .{init,fini}_array.
It seems LLVM realized that and reverted to building with LLVM-soversion == libclang-soversion by default, but the SUSE llvm builds override that with -DCLANG_FORCE_MATCHING_LIBCLANG_SOVERSION:BOOL=OFF. Should I file a bug against the LLVM component?
I'm not aware that this was the reason. What I've read from the posts is that some distributions were running into packaging issues because they have libclang and libclang-cpp in the same package. Or something like that. Having different versions of libclang-cpp or libLLVM in the same process is unfortunately hard to prevent once usage of the library gets more widespread. The API/ABI incompatibilities mean that different parts of the distribution will use different versions, some on the bleeding edge and others lagging behind. My understanding was that symbol versioning should have solved that. The only bug other than yours coming from a libclang incompatibility that I've seen since then was bug 1210176, but that was not an API/ABI incompatibility issue. Rather the user made assumptions about the naming of identifiers that were violated by the new version, but were actually never guaranteed. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com