When updating my system, qttools-6.6.0 failed during configuration with the error "Could not find a configuration file for package "LLVM" that exactly matches requested version "17.0.1". While diagnosing the problem, I discovered that I had llvm 17.0.3 installed (and 17.0.1 wasn't even available to downgrade to), but sys-devel/clang was at 17.0.1 (the world update had yet to deal with clang, it seems). Just to test it out, I decided to manually update clang to 17.0.3 and then try qttools-6.6.0 again, and it worked. In short, the issue is that qttools's configuration phase requires that LLVM and Clang on your system are of the exact same version, but the qttools ebuild does not make sure that this is the case. Though I can't say if the ebuild itself is the issue here; I wouldn't be surprised to find out there are other clang-dependent packages that can run into this issue, and perhaps a solution elsewhere is most appropriate. Reproducible: Always Steps to Reproduce: 1. Have a version of Clang installed without its matching LLVM version (e.g. in the middle of a world update where LLVM has been updated but Clang has yet to follow). Probably has to be the latest version of Clang on your system that's missing its LLVM. 2. Attempt to install qttools-6.6.0 Actual Results: Package fails during CMake configuration, complaining about not being able to find an LLVM version matching the version of Clang it's attempting to use. Expected Results: Package compiles and installs.
Nothing that qttools can do there (all it checks is the major slot, not exact version), your clang is essentially in a "broken" state because it depends exactly on llvm-17.0.1 despite llvm-17.0.1 is gone. Aka, from emerge -pvc llvm: sys-devel/clang-17.0.3 requires ~sys-devel/llvm-17.0.3 At best it can still compile because libs are preserved until then, but anything trying to link with it is likely to fail. Portage should normally make sure this is updated first in a deep world update. Sounds similar to bug #916068 from yesterday with an incomplete update. Albeit this should not happen as part of regular updates and could potentially be a portage bug depending on what happened exactly here.
As far as llvm itself goes, issues like that could be avoidable if we switched to a monorepo ebuild but well.
That makes sense to me, and to be honest that's where I was thinking in the first place. Felt like the issue was more that portage was delaying building clang for too long. (I can say that this package is what broke my emerge -avutDU @world build, so this wasn't the fault of me interrupting an update earlier.) While I certainly can't say much about what portage does or should be doing, I thought of two potential solutions: 1. When a package being installed has a dependency that's also in the install list, portage should ensure that the dependency comes first, if possible. 2. A new ebuild feature that lets LLVM or Clang ebuilds specify that the two packages should be as close together in the order of installs as possible. The idea is that sometimes packages form a "suite" of software together that shouldn't be left in a half-installed state for longer than necessary. Again, I can't pretend I know what the solution is, but I do think the issue is ultimately that LLVM and Clang are ostensibly separate pieces of software, but seem pretty heavily tied together as if they're one thing. (At least, if Clang was truly an independent user of LLVM, I'd expect it to be more tolerant of what version of LLVM you have installed.) Doesn't seem like qttools specifically is the issue, it's just where I ran into the problem.
Not sure how to assign this, so I'm giving it to qt. Please reassign as you see fit.
Current version 6.6.1-r1 cannot compile with: Could not find a configuration file for package "LLVM" that exactly matches requested version "17.0.5". The following configuration files were considered but not accepted: /usr/lib/llvm/17/lib64/cmake/llvm/LLVMConfig.cmake, version: 17.0.6 /usr/lib/llvm/17/lib/cmake/llvm/LLVMConfig.cmake, version: 17.0.6 /usr/lib/llvm/16/lib64/cmake/llvm/LLVMConfig.cmake, version: 16.0.6 /usr/lib/llvm/16/lib/cmake/llvm/LLVMConfig.cmake, version: 16.0.6 Newest update brought llvm and clang to 17.0.6.
My thinking wrt suites is to possibly abuse stable groups for this.
(In reply to Lorenzo Bertini from comment #5) > Current version 6.6.1-r1 cannot compile with: > > Could not find a configuration file for package "LLVM" that exactly matches > requested version "17.0.5". > > The following configuration files were considered but not accepted: > > /usr/lib/llvm/17/lib64/cmake/llvm/LLVMConfig.cmake, version: 17.0.6 > /usr/lib/llvm/17/lib/cmake/llvm/LLVMConfig.cmake, version: 17.0.6 > /usr/lib/llvm/16/lib64/cmake/llvm/LLVMConfig.cmake, version: 16.0.6 > /usr/lib/llvm/16/lib/cmake/llvm/LLVMConfig.cmake, version: 16.0.6 > > Newest update brought llvm and clang to 17.0.6. Sorry, it was my fault here. I updated qttools *before* bringing sys-devel/clang-runtime to 17.0.6. Forget about it.
I hit the same issue. llvm was updated to 17.0.6, but clang wasn't updated first using `emerge -NuDav world`. it is in the list, but qttools is trying to upgrade first and it fails as it expects llvm 17.0.2.
(In reply to Ionen Wolkens from comment #1) > Nothing that qttools can do there (all it checks is the major slot, not > exact version), your clang is essentially in a "broken" state because it > depends exactly on llvm-17.0.1 despite llvm-17.0.1 is gone. Perhaps the ebuild should disable the LLVM CMake check when qttools is built with USE=-clang". Because that's most likely the reason for this error. LLVM gets updated and then qttools gets built before clang update due to USE="-clang".
(In reply to Martin Doucha from comment #9) > (In reply to Ionen Wolkens from comment #1) > > Nothing that qttools can do there (all it checks is the major slot, not > > exact version), your clang is essentially in a "broken" state because it > > depends exactly on llvm-17.0.1 despite llvm-17.0.1 is gone. > > Perhaps the ebuild should disable the LLVM CMake check when qttools is built > with USE=-clang". Because that's most likely the reason for this error. LLVM > gets updated and then qttools gets built before clang update due to > USE="-clang". Oh, didn't notice it failed with USE=-clang (nobody provided a build log in this bug yet, so I've been assuming USE=clang was enabled).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=624edb4460ccd6211cd71bde1f850810c3f3fa1d commit 624edb4460ccd6211cd71bde1f850810c3f3fa1d Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-12-19 15:05:49 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-12-19 15:14:31 +0000 dev-qt/qttools: disable clang test with USE=-clang Normally harmless (tries to find it, either does or not and will not use it either way), but if the cmake files are in broken state then it can abort entirely. Unsure if it fully resolves bug #916098 (for portage, ideally these should still be updated "together" as much as possible), but at least should not trigger on qttools anymore for those not enabling clang (tested by intentionally breaking llvm's cmake files). Closes: https://bugs.gentoo.org/916098 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-qt/qttools/qttools-6.6.1.ebuild | 2 ++ dev-qt/qttools/qttools-6.6.9999.ebuild | 2 ++ dev-qt/qttools/qttools-6.7.9999.ebuild | 2 ++ dev-qt/qttools/qttools-6.9999.ebuild | 2 ++ 4 files changed, 8 insertions(+)
That explains quite a bit and the chain of events makes sense to me now even if it's not ideal.
