dev-libs/libclc-0.2.0_pre20170118 fails to emerge, as it canot properly find (detect) the presence of llvm. >>> Configuring source in /var/tmp/portage/dev-libs/libclc-0.2.0_pre20170118/work/libclc-0.2.0_pre20170118 ... libclc requires LLVM >= 4.0 * ERROR: dev-libs/libclc-0.2.0_pre20170118::gentoo failed (configure phase): * (no error message) * But LLVM is installed: qlist -vI llvm sys-devel/llvm-3.9.1-r1 sys-devel/llvm-4.0.1 sys-devel/llvm-common-4.0.1 Reproducible: Always Steps to Reproduce: 1. try emerging libclc Actual Results: fails to find llvm even though it is present Expected Results: clean build Might be a problem related to LLVM slotting.
This might be related to bug #624034. Please wait a while, sync and retry. If it still fails, then please attach the build log and include 'emerge --info clang llvm'.
(In reply to Michał Górny from comment #1) > This might be related to bug #624034. Please wait a while, sync and retry. > If it still fails, then please attach the build log and include 'emerge > --info clang llvm'. Okay, one thing I want to add though is this: All the files in /usb/bin seem to belong to llvm-3.9 whilst llvm-4 seems to only have files in /usr/x86_64... IIRC. And there is nothing like gcc-config with its softlinks to select the 'active instance'. I did not have time to look at the detection of llvm in libclc, but it might be, libclc only looks at something in /usr/bin and thus thinks only llvm-3.9 is around.
LLVM 4 blocks older versions for a reason. If you have somehow gotten Portage not to unmerge 3.9 for you, please remove it manually. A lot of logic in Gentoo relies on not having slot 0 and another slot installed simultaneously.
(In reply to Michał Górny from comment #3) > LLVM 4 blocks older versions for a reason. If you have somehow gotten > Portage not to unmerge 3.9 for you, please remove it manually. A lot of > logic in Gentoo relies on not having slot 0 and another slot installed > simultaneously. Compilation worked out fine once llvm-3.9 was gone. Question remains: Why did portage not enforce the removal of 3.9 in any way? Neither got it uninstalled, nor was there a blocker of any kind.
$ portageq metadata / installed sys-devel/llvm-4.0.1 RDEPEND sys-libs/zlib:0/0= >=sys-devel/binutils-2.22:*[cxx] dev-libs/libedit:0/0=[abi_x86_32(-),abi_x86_64(-)] >=virtual/libffi-3.0.13-r1:0/0=[abi_x86_32(-),abi_x86_64(-)] >=sys-libs/ncurses-5.9-r3:0/6=[abi_x86_32(-),abi_x86_64(-)] !sys-devel/llvm:0 Do you have the same output?
(In reply to Michał Górny from comment #5) > $ portageq metadata / installed sys-devel/llvm-4.0.1 RDEPEND > sys-libs/zlib:0/0= >=sys-devel/binutils-2.22:*[cxx] > dev-libs/libedit:0/0=[abi_x86_32(-),abi_x86_64(-)] > >=virtual/libffi-3.0.13-r1:0/0=[abi_x86_32(-),abi_x86_64(-)] > >=sys-libs/ncurses-5.9-r3:0/6=[abi_x86_32(-),abi_x86_64(-)] !sys-devel/llvm:0 > > Do you have the same output? portageq metadata / installed sys-devel/llvm-4.0.1 RDEPEND sys-libs/zlib:0/0= >=virtual/libffi-3.0.13-r1:0/0=[abi_x86_64(-)] >=sys-libs/ncurses-5.9-r3:0/6=[abi_x86_64(-)] !sys-devel/llvm:0 Looks a little different. For some odd reason there's not binutils listed. But !sys-devel/llvm:o is present and should have done it's job, if I understand things correctly. Is it posible, that back when I emerged llvm-4.0.1 the portage tree was a little different and made me run into that trap?
Well, the installed package has the blocker, so it must've been there the whole time. The only thing I'm aware that could cause issues like this is if emerge failed or was interrupted between installing new LLVM and unmerging the old one (e.g. while building clang).
(In reply to Michał Górny from comment #7) > Well, the installed package has the blocker, so it must've been there the > whole time. The only thing I'm aware that could cause issues like this is if > emerge failed or was interrupted between installing new LLVM and unmerging > the old one (e.g. while building clang). That might have been the problem. Can't tell for sure any more, it's been a while since I emerged llvm-4.0.1. Maybe I suspended the machine and it did not come up properly again, which lead to an interruption in the emerge process. Thanks for the clarification.
