[opensuse-bugs] [Bug 1179155] New: llvm11 for 15SP3 / Leap15.3
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 Bug ID: 1179155 Summary: llvm11 for 15SP3 / Leap15.3 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: SLES 15 Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs@suse.de Reporter: rguenther@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I'm opening this bug to avoid repeating bug1164454 - SP3 is supposed to get an update to the Mesa LLVM stack again, this time I will pick llvm11. Again SLE 15 SP3 will keep llvm7 as 'llvm' and from the llvm11 set of packages only what is required for Mesa will end up on the media (no clang, etc.) but all this "rest" should be diverted to PackageHub. Since there's that new Jump thing on the plate for Leap 15.3 and Leap 15.3 traditionally wants clang to be new and not old I wonder how we can make these conflicting requirements work this time. My current plan is to simply throw what's in Factory into SP3 and put a big fat note on it what (sub-)packages to ship and what not. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 Richard Biener <rguenther@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aaronpuchert@alice-dsl.net, | |lubos.kocman@suse.com, | |mlin@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c1 --- Comment #1 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Richard Biener from comment #0)
Again SLE 15 SP3 will keep llvm7 as 'llvm' Isn't Mesa the only consumer of llvm in SLE?
But I'm not sure, "whatdependson" doesn't seem to work on SUSE:SLE-15-SP2:GA. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c2 --- Comment #2 from Richard Biener <rguenther@suse.com> --- (In reply to Aaron Puchert from comment #1)
(In reply to Richard Biener from comment #0)
Again SLE 15 SP3 will keep llvm7 as 'llvm' Isn't Mesa the only consumer of llvm in SLE?
But I'm not sure, "whatdependson" doesn't seem to work on SUSE:SLE-15-SP2:GA.
Mesa is currently the only consumer of llvm9 but there are several packages that use clang/llvm for building (rust for example) and those still use llvm7 via the llvm package. I'm now trying to sync up the package structure on SLE to what we have on Factory some more, re-syncing at least the llvm9 copy and more carefully llvm7. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c3 --- Comment #3 from Richard Biener <rguenther@suse.com> --- For the install check issues below we can either add SLE specific conflicts (they will not work with factory based llvm7/9 packages and thus likely Leap) or update the llvm7 stack to the package setup of Factory (there's shuffling around of binaries into a new clang-tools package) and do the same for llvm9. I'd rather not split sources in SP3 so updating llvm7 means updating the package setup for SP1+ and llvm9 means updating for SP2+ (but none of the affected packages are actually shipped on the media there for llvm9 as opposed to llvm7 which accidentially got fully shipped for SP1). For llvm5 of :GA there's still the hard Conflicts: llvm5 in the Factory packages. That said, we can also simply ignore the issue since clang-tools is not supposed to be on the SP3 media (but on PackageHub - where the issue might or might not be a blocker there) ### [install check & file conflicts for x86_64] found conflict of clang-tools-11.0.0-3.2.x86_64 with clang7-7.0.1-3.13.1.x86_64 /usr/bin/clang-format-diff /usr/bin/clang-tidy-diff /usr/bin/git-clang-format /usr/bin/run-clang-tidy found conflict of clang-tools-11.0.0-3.2.x86_64 with llvm7-7.0.1-3.13.1.x86_64 /usr/bin/hmaptool found conflict of clang-tools-11.0.0-3.2.x86_64 with llvm9-9.0.1-3.3.1.x86_64 /usr/bin/hmaptool -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 Richard Biener <rguenther@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gyribeiro@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 Radoslav Tsvetkov <rtsvetkov@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P1 - Urgent CC| |rtsvetkov@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c8 --- Comment #8 from Richard Biener <rguenther@suse.com> --- I have submitted a change to llvm7 to Conflict with clang-tools. I fear we cannot simply update SP2 llvm9 from Factory since that now has clang-tools but does not build them (as it comes from newer llvm there) but we still need it to build Mesa-drivers in SP2 (in SP2 llvm9 is the newest llvm and clang9-devel requires clang-tools). Note for SP4 we'll have the issue that we have clang-tools from multiple packages but clang-tools isn't versioned :/ The Factory/leap way would be to have separate sources for each llvm version in each product. Meh. IMHO it should be clang-tools%{_sonum} providing clang-tools = %{version} and the Recommends/Requires from clang/clang-devel should be to clang-tools >= %{version}. For the OBS solver that might be ambiguous but GCC solves this with Prefer: in the prjconfs. At least this avoids needing to touch packages again and again. Aaron, would you be opposed to such a change in the Factory packages? (I'd switch building of individual clang-tools%{_sonum} back on so SLE could 1:1 use the Factory packages which seems to be a requirement here) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c10 --- Comment #10 from Richard Biener <rguenther@suse.com> --- (In reply to Richard Biener from comment #8)
IMHO it should be clang-tools%{_sonum} providing clang-tools = %{version} and the Recommends/Requires from clang/clang-devel should be to clang-tools >= %{version}. For the OBS solver that might be ambiguous but GCC solves this with Prefer: in the prjconfs. At least this avoids needing to touch packages again and again.
Aaron, would you be opposed to such a change in the Factory packages? (I'd switch building of individual clang-tools%{_sonum} back on so SLE could 1:1 use the Factory packages which seems to be a requirement here)
I've prepped this for llvm11 in home:rguenther:branches:devel:tools:compiler/llvm11 I do have similar issues with libcxx and libabi of course ... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c11 --- Comment #11 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Richard Biener from comment #3)
install check & file conflicts for x86_64]
found conflict of clang-tools-11.0.0-3.2.x86_64 with clang7-7.0.1-3.13.1.x86_64 /usr/bin/clang-format-diff /usr/bin/clang-tidy-diff /usr/bin/git-clang-format /usr/bin/run-clang-tidy
found conflict of clang-tools-11.0.0-3.2.x86_64 with llvm7-7.0.1-3.13.1.x86_64 /usr/bin/hmaptool
found conflict of clang-tools-11.0.0-3.2.x86_64 with llvm9-9.0.1-3.3.1.x86_64 /usr/bin/hmaptool
In Factory clang-tools has # Some binaries used to be in the clang package. Conflicts: clang5 Conflicts: clang6 # hmaptool used to be contained in the llvm package. Conflicts: llvm5 Conflicts: llvm6 So for llvm7 I'd just add them here. The hmaptool conflict with llvm9 is probably because Leap's llvm9 doesn't have https://build.opensuse.org/request/show/782745, thus clang-tools yet? (In reply to Richard Biener from comment #8)
I have submitted a change to llvm7 to Conflict with clang-tools. I fear we cannot simply update SP2 llvm9 from Factory since that now has clang-tools but does not build them (as it comes from newer llvm there) but we still need it to build Mesa-drivers in SP2 (in SP2 llvm9 is the newest llvm and clang9-devel requires clang-tools). To be honest, I don't like the artificial dependency clangX-devel's CMake files have on binaries. But perhaps this can be solved with https://build.opensuse.org/package/rdiff/devel:tools:compiler/llvm9?linkrev=base&rev=42, which allows any clang-tools version. Perhaps you also need https://build.opensuse.org/package/rdiff/devel:tools:compiler/llvm9?linkrev=base&rev=56, in case the binaries changed.
Note for SP4 we'll have the issue that we have clang-tools from multiple packages but clang-tools isn't versioned :/ The Factory/leap way would be to have separate sources for each llvm version in each product. Meh. Hmm, don't we have the same problem for existing packages like python3-clang?
IMHO it should be clang-tools%{_sonum} providing clang-tools = %{version} and the Recommends/Requires from clang/clang-devel should be to clang-tools >= %{version}. I went with an unversioned package in https://build.opensuse.org/request/show/782745 because clang-tools contains mostly scripts that use the unversioned executables. If we allowed multiple packages to coexist, this would lead to a situation where e.g. git-clang-format-9 would use clang-format, which might point to clang-format-11. Patching the scripts would be non-trivial.
For the OBS solver that might be ambiguous but GCC solves this with Prefer: in the prjconfs. At least this avoids needing to touch packages again and again. GCC is a lot cleaner fortunately. I'm also not a big fan of using update-alternatives to provide the unversioned executables and would rather go
The package contains basically all clang files that can't coexist in multiple versions. Also there was already a precedence with python3-clang and of course libc++. the GCC way. (Bug 1120098, comment 1, but the maintainer at the time didn't like that.)
Aaron, would you be opposed to such a change in the Factory packages? (I'd switch building of individual clang-tools%{_sonum} back on so SLE could 1:1 use the Factory packages which seems to be a requirement here) With the changes I mentioned above this shouldn't be needed, I hope. Unless I'm missing something.
(In reply to Richard Biener from comment #10)
I do have similar issues with libcxx and libabi of course ... How was this solved previously? The idea of turning the builds off for old versions long precedes my stint at maintainership, it goes to back to https://build.opensuse.org/package/rdiff/devel:tools:compiler/llvm?linkrev=base&rev=478 in 2016.
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c16 Manfred Hollstein <manfred.h@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manfred.h@gmx.net --- Comment #16 from Manfred Hollstein <manfred.h@gmx.net> --- (In reply to Richard Biener from comment #2)
(In reply to Aaron Puchert from comment #1)
(In reply to Richard Biener from comment #0)
Again SLE 15 SP3 will keep llvm7 as 'llvm' Isn't Mesa the only consumer of llvm in SLE?
But I'm not sure, "whatdependson" doesn't seem to work on SUSE:SLE-15-SP2:GA.
Mesa is currently the only consumer of llvm9 but there are several packages that use clang/llvm for building (rust for example) and those still use llvm7 via the llvm package.
rust is especially interesting to me. I currently cannot build my various rust versions (needed to build MozillaFirefox ESR vs. Release) anymore; details can be found in <https://build.opensuse.org/package/show/home:manfred-h:devel:languages:rust:rust-1.46/rust-1.46.0> and <https://build.opensuse.org/package/show/home:manfred-h:devel:languages:rust:rust-1.47/rust-1.47.0>. Both apparently need an "llvm-devel >= 8.0"; I could enable the builtin version of LLVM as it's done for Leap <= 15.1 or various SLE versions, but as Leap 15.2 has a proper llvm-devel I'd suggest we go down that route to ensure Leap 15.3 has at least the version provided by Leap 15.2 - or even newer. In the interest to allow building of rust > 1.45, I'd appreciate a solution here. Thx!
I'm now trying to sync up the package structure on SLE to what we have on Factory some more, re-syncing at least the llvm9 copy and more carefully llvm7.
That would be really great! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c17 --- Comment #17 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- We have llvm11 in Leap 15.3 now, but the llvm metapackage is still at version 7, which is a downgrade from Leap 15.2, compare https://build.opensuse.org/package/show/openSUSE:Leap:15.2/llvm (9.0.1) https://build.opensuse.org/package/show/openSUSE:Leap:15.3/llvm (7.0.1) That doesn't seem right. Hard to tell for me what the implications are, because I think some packages are using hardcoded LLVM versions on Leap. But there are definitely packages that BuildRequire the metapackage and I think I'll get complaints if they link to such outdated library versions. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c18 Richard Biener <rguenther@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(lubos.kocman@suse | |.com) --- Comment #18 from Richard Biener <rguenther@suse.com> --- (In reply to Aaron Puchert from comment #17)
We have llvm11 in Leap 15.3 now, but the llvm metapackage is still at version 7, which is a downgrade from Leap 15.2, compare
https://build.opensuse.org/package/show/openSUSE:Leap:15.2/llvm (9.0.1) https://build.opensuse.org/package/show/openSUSE:Leap:15.3/llvm (7.0.1)
That doesn't seem right. Hard to tell for me what the implications are, because I think some packages are using hardcoded LLVM versions on Leap. But there are definitely packages that BuildRequire the metapackage and I think I'll get complaints if they link to such outdated library versions.
I guess it's the call of the release managers whether they want to replace the SLE provided llvm metapackage with one we'd fork in Leap 15.3. I think diverting this to PackageHub is a no-go since the same packages may not exist on both SLE and PackageHub. So - Lubos? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c19 --- Comment #19 from Richard Biener <rguenther@suse.com> --- Oh, and the best solution would be to drop 'llvm' (the meta package) from SLE and only provide it via PackageHub. We'd of course need to keep the "old" 'llvm' (in version 7) in the SLE build system or alternatively arrange all packages that require llvm for building / running to use versioned requires (and binaries). Or divert all those packages to PackageHub as well. Anyway, probably way too late now so forking of 'llvm' is the only realistic plan. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c20 --- Comment #20 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Richard Biener from comment #19)
Oh, and the best solution would be to drop 'llvm' (the meta package) from SLE and only provide it via PackageHub. We'd of course need to keep the "old" 'llvm' (in version 7) in the SLE build system or alternatively arrange all packages that require llvm for building / running to use versioned requires (and binaries). Or divert all those packages to PackageHub as well. Out of curiosity, can you run "ibs whatdependson" on the llvm metapackage in SLE? That would make it easier to understand the impact. There is probably lots of packages in Leap/Backports though, judging from the same query in Factory.
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c21 --- Comment #21 from Richard Biener <rguenther@suse.com> --- (In reply to Aaron Puchert from comment #20)
(In reply to Richard Biener from comment #19)
Oh, and the best solution would be to drop 'llvm' (the meta package) from SLE and only provide it via PackageHub. We'd of course need to keep the "old" 'llvm' (in version 7) in the SLE build system or alternatively arrange all packages that require llvm for building / running to use versioned requires (and binaries). Or divert all those packages to PackageHub as well. Out of curiosity, can you run "ibs whatdependson" on the llvm metapackage in SLE? That would make it easier to understand the impact. There is probably lots of packages in Leap/Backports though, judging from the same query in Factory.
That yields for 15:GA Mesa-drivers bcc beignet gnome-builder gnome-code-assistance libclc meson-testsuite rust and for 15:SP1:GA Mesa-drivers bcc beignet gnome-builder gnome-code-assistance libclc meson-testsuite rust and nothing in SP2/3 or the Update repos (seems project inheritance doesn't work for whatdependson). The above is for x86_64. Since SP2 Mesa-drivers depends on a versioned llvm version. Oddly enough there's a bcc in SP3 as well and it depends on llvm but osc whatdependson doesn't list it. Thus take this with a grain of salt. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c22 --- Comment #22 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Richard Biener from comment #21)
Mesa-drivers Depends on llvm11 directly now.
bcc Seems to depend on llvm directly, which means it would use llvm7 in SLE/Leap. Which is probably fine, but BPF is a relatively new target, so an update is probably not a bad idea.
beignet Builds with llvm7 latest anyway. Strangely Factory has a different specfile specifically asking for llvm7, but SLE still uses the metapackage. I don't see a reason to not update though.
gnome-builder gnome-code-assistance These are probably using libclang. I think using a newer version wouldn't hurt. If we don't, we'll have to live with Leap users having Clang 7 under the hood as well.
libclc This should probably use the same LLVM version that Mesa is using. The package consists of LLVM IR files, and while the format is mostly stable I'm not sure if that's guaranteed. Package is also somewhat outdated... but not sure what the update policy is here. Though if you update Mesa, then this should be fine to update as well.
meson-testsuite No idea what the test suite is doing with LLVM, but probably not so important.
rust Interesting case. Rust uses the somewhat unstable LLVM API, which means it typically needs changes for every new LLVM version. So it should probably not require the metapackage but something like llvm-devel-provider < (N+1).0.0, or cmake(LLVM) < (N+1).0.0 where N is the latest supported version.
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1179155 http://bugzilla.opensuse.org/show_bug.cgi?id=1179155#c23 Aaron Puchert <aaronpuchert@alice-dsl.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Flags|needinfo?(lubos.kocman@suse | |.com) | --- Comment #23 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- We have llvm11 in SLE 15 SP3 and thus also Leap 15.3. I have opened bug 1184920 for getting a newer llvm metapackage into Leap 15.3 so that users don't have to suffer a downgrade there. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com