See upstream bug. I will attach a kdelibs buildlog which reproduces this problem under portage-multilib for people who have multilib-no-symlink (a.k.a. me). The basic idea is that cmake enables by default this property called FIND_LIBRARY_USE_LIB64_PATHS . When this property is enabled and when CMake's C++ code detects that the build environment is 64-bit (by checking the size of the C++ compiler's void* pointer), CMake will internally add the string "lib64" in many places where it uses the string "lib". CMake doesn't have support for automatically adding "lib32" to these searchpaths during a 32-bit build. Why does this matter? The attached kdelibs log is one example of a CMakeLists.txt which expects CMake to add /usr/lib32 to one of its searchpaths. The particular searchpath that matters in this case is FIND_PACKAGE(<package name> NO_MODULE). See CMake's documentation on the list of searchpaths searched when NO_MODULE is specified to FIND_PACKAGE. Also, FIND_LIBRARY_USE_LIB64_PATHS adds paths to the FIND_LIBRARY() CMake function. The kdelibs failure doesn't happen when compiling a 64-bit kdelibs on my machine. The failure of the to-be-attached 32-bit build of kdelibs log shouldn't happen, because I have the following list of files installed for dev-util/automoc: ohnobinki@ohnopublishing ~/cmake $ qlist -e automoc /usr/bin/automoc4 /usr/lib/debug/usr/bin/automoc4.debug /usr/lib32/automoc4/automoc4.files.in /usr/lib32/automoc4/Automoc4Config.cmake /usr/lib32/automoc4/Automoc4Version.cmake /usr/lib64/automoc4/automoc4.files.in /usr/lib64/automoc4/Automoc4Config.cmake /usr/lib64/automoc4/Automoc4Version.cmake ohnobinki@ohnopublishing ~/cmake $ ls /usr/lib32/automoc4/Automoc4Config.cmake /usr/lib32/automoc4/Automoc4Config.cmake ohnobinki@ohnopublishing ~/cmake $ ls /usr/lib/automoc4/Automoc4Config.cmake ls: cannot access /usr/lib/automoc4/Automoc4Config.cmake: No such file or directory I do not like having potentially ABI-specific stuff in my /usr/lib directory as having such things there is allowing failures to go unnoticed longer.
Created attachment 248476 [details] /tmp/kdelibs-4.5.1-build.log
Created attachment 248478 [details] /tmp/emerge--info.txt
Created attachment 248601 [details] files/cmake-2.8.1-portage-multilib-lib32.patch Same patch as that available at the upstream bug URL. However, I added some notes to the top of the patch describing its purpose and whatnot.
(In reply to comment #3) > Same patch as that available at the upstream bug URL. However, I added some > notes to the top of the patch describing its purpose and whatnot. Isn't that just a workaround for a feature broken my design?
(In reply to comment #4) > Isn't that just a workaround for a feature broken my design? It is completion of upstream's method for fixing the /usr/lib64 problem by informing them that /usr/lib32 exists while at the same time duplicating C++ code :-).
Created attachment 251089 [details, diff] cmake-2.8.1-portage-multilib-lib32.patch This version actually enables the FIND_LIBRARY_USE_LIB32_PATHS property by default which is what I intended to do in the original patch ;-).
We should wait for upstream here.
*** Bug 378993 has been marked as a duplicate of this bug. ***
Comment on attachment 251089 [details, diff] cmake-2.8.1-portage-multilib-lib32.patch the active multilib path could literally be anything. hardcoding "lib" or "lib32" or "lib64" doesn't actually solve the problem.
*** Bug 426936 has been marked as a duplicate of this bug. ***
As bug 426936 has seen more activity recently, copying some infos from the report: (In reply to Dainius Masiliūnas from comment #11) > Created attachment 426408 [details] > libqtxdg build.log > > Here's an example of such build failure. This seems to happen with pretty > much any cmake package that requires Qt (and possibly any other packages > that ship their own cmake modules). > > This one can be worked around by using: > Qt5Widgets_DIR=/usr/libx32/cmake/Qt5Widgets > Qt5Xml_DIR=/usr/libx32/cmake/Qt5Xml Qt5DBus_DIR=/usr/libx32/cmake/Qt5DBus > emerge libqtxdg (In reply to Dainius Masiliūnas from comment #12) > Here the workaround is like when building cmake itself: > CMAKE_PREFIX_PATH=/usr/libx32 (In reply to Steven Newbury from comment #14) > Upstream bug: https://cmake.org/Bug/view.php?id=15994
*** Bug 585166 has been marked as a duplicate of this bug. ***
Good news, everyone! It seems that a patch for this has finally been merged upstream [1]. There's also 3.5 version attached on the llvm bug [2] but I don't know if it's exactly the same as upstream commit. It was mentioned that it applies to 3.4,2 as well. [1]:https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=896ad251 [2]:https://585166.bugs.gentoo.org/attachment.cgi?id=437088
(In reply to Michał Górny from comment #13) > Good news, everyone! It seems that a patch for this has finally been merged > upstream [1]. There's also 3.5 version attached on the llvm bug [2] but I > don't know if it's exactly the same as upstream commit. It was mentioned > that it applies to 3.4,2 as well. > > [1]:https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=896ad251 > [2]:https://585166.bugs.gentoo.org/attachment.cgi?id=437088 They are not identical, there have been formatting and minor structural changes. The changes between the patches can been seen here: https://paste.fedoraproject.org/377515/56316651/
(In reply to Michał Górny from comment #13) unfortunately they just extended their blind hacks by hardcoding more assumptions and literal "lib32" srings, so we still have problems for some ABIs.
(In reply to SpanKY from comment #15) > (In reply to Michał Górny from comment #13) > > unfortunately they just extended their blind hacks by hardcoding more > assumptions and literal "lib32" srings, so we still have problems for some > ABIs. Hardcoding lib64, lib32 is better than failing to detect libraries there, isn't it? What kind of ABIs do we still lack? Is there another way of detecting the library folder properly?
(In reply to SpanKY from comment #15) > (In reply to Michał Górny from comment #13) > > unfortunately they just extended their blind hacks by hardcoding more > assumptions and literal "lib32" srings, so we still have problems for some > ABIs. Did you really expect anything more from a build system that follows the idea 'let's hardcode every possible existing system until things seem to work well'?
Apparently someone already did something similar for x32: https://github.com/sjnewbury/x32/blob/master/dev-util/cmake/files/cmake-3.4.3-libx32.patch If they accepted the other patch, this one might make it upstream as well (more hardcoding ftw).
(In reply to EoD from comment #16) cmake's philosphy for how to detect libs/headers is largely broken to begin with. libx32 is the most common example, but just the tip -- ignoring multiarch (since we don't use it, but it's just as broken w/cmake), gcc has other multilib setups as well to the point where hardcoding anything makes no sense.
Does this mean this bug is resolved now, or what further action is required?
(In reply to Michael Palimaka (kensington) from comment #20) > Does this mean this bug is resolved now, or what further action is required? Not yet, x32 does still have the same issue. The patch for lib32 does not apply to libx32 unfortunately. I can offer a rebased version of the lib32 patch for 3.4.3, though. This could be put in the gentoo tree.
(In reply to Michael Palimaka (kensington) from comment #20) > Does this mean this bug is resolved now, or what further action is required? You need to apply the backported patch to our ebuilds.
i've re-opened bug 426936. we can track libx32 support there. once a cmake version hits the tree that includes the lib32 patch, we'll close this.
Created attachment 437284 [details, diff] Rebased lib32 patch for cmake 3.4.3 As already mentioned, this is the lib32 patch for cmake-3.4.3. The patch for cmake/next: https://cmake.org/gitweb?p=cmake.git;a=commit;h=896ad251de49f167f4ce3cbbcf9a6cce85a16681
*** Bug 587950 has been marked as a duplicate of this bug. ***
Since this is now necessary to build LLVM 3.9, I've went ahead and backported it. It's p.masked for testing now, though. commit 08ad139374c65516481275579264319c74b4afcb Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Sun Aug 28 16:45:49 2016 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Sun Aug 28 18:19:24 2016 dev-util/cmake: Backport find_library() lib32 fix, #338492
This has since been unmasked.
