Bugzilla – Bug 1198525
libclang soversion is still '13' in llvm14, causing issues in qt-creator, libqt5-qttools and qt6-tools
Last modified: 2022-04-19 09:54:54 UTC
In qt-creator.spec: # clangcodemodel hardcodes clang include paths: QTCREATORBUG-21972 %requires_eq libclang%{_llvm_sonum} In qt6-tools.spec: # qdoc hardcodes clang include paths: boo#1109367, QTBUG-70687 %requires_eq libclang%{_llvm_sonum} This is currently unresolvable because the sover of libclang has not increased with the latest release: llvm14 still provides libclang13. Now I could add an rpm macro for the sover of libclang (I likely will), but there is another issue: Upstream wants to release a new patch level version every two weeks. [1] That would mean quite frequent rebuilds. I think it shouldn't be awfully hard to fix: using clang_getClangVersion you should be able to determine the patch-level version at runtime, and then fiddle together the path as CXString version = clang_getClangVersion(); sprintf(..., "%{_libdir}/clang/%s/include", version.data); clang_disposeString(version); Don't forget to dispose, otherwise there will be a leak. There is probably an equivalent call in libclang-cpp.so, this is assuming you only want to use libclang.so. [1] https://discourse.llvm.org/t/llvm-14-0-1-release/61700
KDevelop doesn't fail to build, but # contains the headers that are needed for the C++ parser to work (see boo#1119186) Requires: clang%(rpm -q --qf '%''{version}' clang-devel | cut -d. -f1) is also unnecessary by now: Leap >= 15.3 should have the files in libclang, and KDevelop already uses clang_getClangVersion in plugins/clang/duchain/clanghelpers.cpp. Looking at this... it's not as easy as I suggested: QString ClangHelpers::clangVersion() { static const auto clangVersion = []() -> QString { // NOTE: The apidocs for clang_getClangVersion() clearly state it shouldn't be used for parsing // but there's no other way to retrieve the Clang version at runtime at this point... const ClangString version(clang_getClangVersion()); clangDebug() << "Full Clang version:" << version; // samples: // clang version 6.0.1 (trunk 321709) (git@github.com:llvm-mirror/llvm.git 5136df4d089a086b70d452160ad5451861269498) // clang version 7.0.0-svn341916-1~exp1~20180911115939.26 (branches/release_70) // Ubuntu clang version 11.0.0-2 QRegularExpression re(QStringLiteral("clang version (\\d+\\.\\d+\\.\\d+)")); const auto match = re.match(version.toString()); if (!match.hasMatch()) return {}; return match.captured(1); // return e.g. 7.0.0 }(); return clangVersion; } I'll see if we can add a proper API at upstream, but for now, this will have to do.
The unresolvable issue needs to be addressed in the spec, not in the code.
unresolvable: conflict for providers of libclang13 >= 14.0.0 needed by clang14-devel, (provider libclang13 conflicts with llvm13-libclang13) isn't a qt-creator or qdoc issue however.
(In reply to Christophe Giboudeaux from comment #3) > unresolvable: conflict for providers of libclang13 >= 14.0.0 needed by > clang14-devel, (provider libclang13 conflicts with llvm13-libclang13) Different providers of libclang13 have to conflict with each other. But the prjconf of Factory [1] has Prefer: libclang13 The likely issue is that because libqt5-qttools didn't get a rebuild, its subpackage libqt5-qttools-doc still requires libclang13 = 13.0.1. That subpackage is required by qt-creator via cmake(Qt5DocTools), but QtCreator wants to build against the new llvm14 which requires libclang13 >= 14.0.0. So I think it is caused by %requires_eq (admittedly on libqt5-qttools, I missed that because OBS didn't attempt a rebuild for it). [1] https://build.opensuse.org/projects/openSUSE:Factory/prjconf
> %{_llvm_sonum} is still '13' in llvm14 Nope: $ rpm -E %{_llvm_sonum} 14 $ grep _llvm_sonum /usr/lib/rpm/macros.d/* /usr/lib/rpm/macros.d/macros.llvm:%_llvm_sonum 14 $ rpm -qf /usr/lib/rpm/macros.d/macros.llvm llvm14-devel-14.0.0-1.2.x86_64
(In reply to Aaron Puchert from comment #0) > In qt-creator.spec: > > # clangcodemodel hardcodes clang include paths: QTCREATORBUG-21972 > %requires_eq libclang%{_llvm_sonum} > > In qt6-tools.spec: > > # qdoc hardcodes clang include paths: boo#1109367, QTBUG-70687 > %requires_eq libclang%{_llvm_sonum} > > This is currently unresolvable because the sover of libclang has not > increased with the latest release: llvm14 still provides libclang13. Correction: %requires_eq turns into a no-op if the package doesn't exist, and this isn't the problem. The problem is that libqt5-qttools and qt6-tools haven't been rebuild since the update and still require libclang13 = 13.0.1, which makes them practically uninstallable and which makes qt-creator and qt6-tools:docs unresolvable, as llvm14-devel requires libclang13 >= 14.0.0.
Dimstar, opinion? - llvm14 creates a libclang13 package - llvm13-libclang13 'provides' libclang13 https://build.opensuse.org/package/show/openSUSE:Factory/qt6-tools, https://build.opensuse.org/package/show/openSUSE:Factory/qt-creator are unresolvable because of this.
Created attachment 858236 [details] PoC patch for qdoc 5.15 Stefan commented on QTCREATORBUG-21972 to mention clang::driver::Driver::GetResourcesPath. That appears to work here, but unfortunately qdoc uses the clang-c API only, which doesn't appear to expose that method... PoC patch for qdoc 5.15 is attached. Qt is also distributed as a "relocatable" environment (official builds), i.e. it doesn't use hardcoded absolute paths anywhere. I'm not sure how this is currently meant to work.