Created attachment 453256 [details] compressed build log Hi! My interpretation of the build log is that 64bit /usr/lib/libffi.so is used when linking a 32bit library: # file -L /usr/lib/libffi.so /usr/lib/libffi.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped Please see the log for details. Best Sebastian
What is your CMake version?
(In reply to Michał Górny from comment #1) > What is your CMake version? 3.6.3
That's weird. It seems that this CMake version has the lib32 patch. Are you sure you're not using a custom ebuild or sth?
(In reply to Michał Górny from comment #3) > That's weird. It seems that this CMake version has the lib32 patch. Are you > sure you're not using a custom ebuild or sth? Yes: >>> Emerging (66 of 92) sys-devel/llvm-3.9.0-r1::gentoo >>> Failed to emerge sys-devel/llvm-3.9.0-r1, Log file: >>> '/var/log/portage/logdir/sys-devel:llvm-3.9.0-r1:20161113-141526.log' >>> Jobs: 65 of 92 complete, 1 failed Load avg: 7.16, 9.06, 9.95 *** Resuming merge...
(In reply to Sebastian Pipping from comment #4) > (In reply to Michał Górny from comment #3) > > That's weird. It seems that this CMake version has the lib32 patch. Are you > > sure you're not using a custom ebuild or sth? > > Yes: > > > >>> Emerging (66 of 92) sys-devel/llvm-3.9.0-r1::gentoo > >>> Failed to emerge sys-devel/llvm-3.9.0-r1, Log file: > >>> '/var/log/portage/logdir/sys-devel:llvm-3.9.0-r1:20161113-141526.log' > >>> Jobs: 65 of 92 complete, 1 failed Load avg: 7.16, 9.06, 9.95 > *** Resuming merge... I was actually asking about CMake. But I guess we'll need to dig into that deeper. Could you start a new build, let it go past src_configure() and paste the 32-bit CMakeFiles/CMake{Output,Error}.*?
Created attachment 453332 [details] x86_32.x86/CMakeFiles/CMakeError.log.xz
Created attachment 453334 [details] x86_32.x86/CMakeFiles/CMakeOutput.log.xz
I'm sorry but I really see nothing obviously wrong here. It's clearly CMake's find_library() finding the wrong library. Looking at the patch... do you happen to have /etc/debian_version in your system?
(In reply to Michał Górny from comment #8) > Looking at the patch... do you happen to have /etc/debian_version in your > system? Actually yes. It's needed for www-client/chromium-bin-debian.
(In reply to Sebastian Pipping from comment #9) > (In reply to Michał Górny from comment #8) > > Looking at the patch... do you happen to have /etc/debian_version in your > > system? > > Actually yes. It's needed for www-client/chromium-bin-debian. Errr... then I'm afraid I can't help you. This file makes CMake believe it's running on Debian and lib32 isn't used on Debian. Reassigning to CMake maintainers, in case they want to improve the find_library() logic. This probably also breaks Gentoo Prefix on Debian. Can't promise you they'll do anything about it though. Your other option is to switch to the lib/lib64 layout (also called SYMLINK_LIB=no).
(In reply to Michał Górny from comment #10) > Your other option is to switch to the lib/lib64 layout (also called > SYMLINK_LIB=no). Hmm, I actually may be wrong here. I suspect CMake may ignore lib64 as well when it's running Debian. Feel like multiarch? ;-)
I found a way to patch use of /etc/debian_version out of www-client/chromium-bin-debian::betagarden now.
From Modules/Platform/Linux.cmake: # Debian has lib32 and lib64 paths only for compatibility so they should not be # searched. if(NOT CMAKE_CROSSCOMPILING AND EXISTS "/etc/debian_version") set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS FALSE) set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE) endif() It would be possible to fix this by patching in a conditional on CMAKE_GENTOO_BUILD, or reverting the property in our build rules file. However, there's a few other place this check is used so I wonder if it will be worth the effort to maintain the patches or if it's better to just declare this configuration unsupported.
I haven't heard anything else here for a long time, so feel free to reopen if some action does need to be taken.
