Summary: | dev-util/cmake does not search libx32 directories (was media-libs/phonon-4.6.0-r1 fails to build for x32 ABI) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | devsk <funtoos> |
Component: | Current packages | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | codegeek98, dschridde+gentoobugs, egorov_egor, EoD, luke-jr+gentoobugs, pastas4, pavel.riha, tdalman |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 393673 | ||
Attachments: |
build.log
libqtxdg build.log kde-frameworks/kwindowsystem build.log 0001-Teach-find_library-and-find_package-to-search-lib32.patch 0002-Specify-custom-lib-suffix.patch cmake 3.7 find_library custom lib suffix (from upstream) portage cmake-utils.eclass patch |
Description
devsk
2012-07-17 04:04:58 UTC
Created attachment 318404 [details]
build.log
It seems to be failing to find automoc4 but automoc4 is already there.
# q files automoc
/usr/libx32/automoc4/automoc4.files.in
/usr/libx32/automoc4/Automoc4Version.cmake
/usr/libx32/automoc4/Automoc4Config.cmake
/usr/bin/automoc4
Is this thing looking for hardcoded path of /usr/lib/automoc4/Automoc4Config.cmake? Is that the issue?
Indeed that's the issue. I created a symlink for automoc4 in /usr/lib/ and build proceeds further. and it builds and installs fine after this. (In reply to comment #1) > Is this thing looking for hardcoded path of > /usr/lib/automoc4/Automoc4Config.cmake? Is that the issue? Indeed, and it works on plain amd64 because /usr/lib is a symlink to /usr/lib64. This is an issue with CMake not searching the correct directories. I have prepared an initial patch and will seek some feedback from upstream. Michael, have you sent an upstream request for this issue already ? (In reply to Tolga Dalman from comment #6) > Michael, have you sent an upstream request for this issue already ? I thought I did, but I can't find anything so I guess not. We did apply this patch[1], but I don't remember if that's relevant or not. [1]: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-util/cmake/files/cmake-2.8.10-more-no_host_paths.patch phonon overrides the system FindPackageHandleStandardArgs.cmake ... not sure this is cmake's fault after all? Potential workaround: phonon builds if you export CMAKE_PREFIX_PATH=/usr/libx32 I can confirm this issue when building cmake-3.3.1-r1. It fails to find its own libraries. I can also confirm the workaround in Comment #9. It works to build cmake properly itself. However, there is still a problem for packages like SDDM, which can't find /usr/libx32/cmake/Qt5Core and other CMake modules. For those, the paths have to be given manually while emerging too, such as Qt5Core_DIR="/usr/libx32/cmake/Qt5Core", repeated for every dependent package. It's doable, but quite annoying. 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
Created attachment 426418 [details]
kde-frameworks/kwindowsystem build.log
Here's another example, this time a link failure: cmake finds the ABI=64 version of the library before it finds the ABI=x32 version of the file, and then tries to link it, of course unsuccessfully.
Here the workaround is like when building cmake itself: CMAKE_PREFIX_PATH=/usr/libx32
As a side-note, app-text/poppler, upon not finding Qt5 due to this bug, silently falls back to -qt5. That breaks everything that depends on poppler[qt5], because portage is not aware of that. I'm pretty sure that such silent fallbacks are undesirable, but I'm not sure if this warrants opening a bug against poppler? Upstream bug: https://cmake.org/Bug/view.php?id=15994 *** This bug has been marked as a duplicate of bug 338492 *** going to re-open as upstream decided to just "fix" the lib32 case I opened a new upstream bug at: https://gitlab.kitware.com/cmake/cmake/issues/16216 Turns out they migrated all issues from Mantis anyway, so the actual issue is now at: https://gitlab.kitware.com/cmake/cmake/issues/15994 Created attachment 449564 [details, diff]
0001-Teach-find_library-and-find_package-to-search-lib32.patch
Created attachment 449566 [details, diff] 0002-Specify-custom-lib-suffix.patch I found a patch on the cmake ML which allows setting libx32 manually: http://public.kitware.com/pipermail/cmake-developers/2016-June/028646.html I backported the patch (and its predecessor "Teach find_library and find_package to search lib32 paths" to 3.5.2. Additionally to the patch, I added the following line to cmake-utils.eclass in order to make it work: > --- /a/usr/portage/eclass/cmake-utils.eclass 2016-10-08 12:13:06.000000000 > +++ /b/usr/portage/eclass/cmake-utils.eclass 2016-10-08 14:27:15.499299864 > @@ -595,4 +595,5 @@ > cat > "${common_config}" <<- _EOF_ || die > SET (LIB_SUFFIX ${libdir/lib} CACHE STRING "library path suffix" FORCE) > + SET (FIND_LIBRARY_USE_CUSTOM_SUFFIX TRUE CACHE BOOL "force usage of LIB_SUFFIX as lib search path" FORCE) > SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH "Output directory for libraries") > _EOF_ This seems to fix building llvm-3.9.0 and llvm-9999 on my x32 mulitlib system. I'm currently working to get x32 support upstreamed: https://gitlab.kitware.com/cmake/cmake/merge_requests/532 (In reply to Steven Newbury from comment #21) > I'm currently working to get x32 support upstreamed: > https://gitlab.kitware.com/cmake/cmake/merge_requests/532 interesting! Your thread also says that a variant of my attached patch here has been merged to master in https://gitlab.kitware.com/cmake/cmake/commit/503f25d490e56dfc1d3dc894e1fc1bd3e7e89e81 I will try to rebase it on top of 3.7 and add it to the bugtracker. Created attachment 465848 [details, diff] cmake 3.7 find_library custom lib suffix (from upstream) A copy of the upstream patch. It can directly be applied on 3.7.2: https://gitlab.kitware.com/cmake/cmake/commit/503f25d490e56dfc1d3dc894e1fc1bd3e7e89e81.patch Created attachment 465850 [details, diff]
portage cmake-utils.eclass patch
With this patch for portage and the "custom lib suffix" patch, I was able to successfully build sys-devel/llvm-3.9.1 on my x32 multilib system.
There are two new files in the portage tree, which contain the two x32 patches from upstream. New files: dev-util/cmake/cmake-3.7.2-r10.ebuild dev-util/cmake/files/cmake-3.7.2-x32.patch Patches: https://gitlab.kitware.com/cmake/cmake/merge_requests/532 https://gitlab.kitware.com/cmake/cmake/merge_requests/533 I can confirm that cmake-3.7.2-r10 works, at least for building some of the KF5 packages. I'm still in the middle of rebuilding my system, so we'll see if any issues crop up, but overall it's looking good. Mind you, the patch is not in the cmake-3.8.1 ebuild, and that one doesn't work. I take it the patch was integrated into mainline CMake for 3.9? (In reply to Dainius Masiliūnas from comment #26) > I can confirm that cmake-3.7.2-r10 works, at least for building some of the > KF5 packages. I'm still in the middle of rebuilding my system, so we'll see > if any issues crop up, but overall it's looking good. > > Mind you, the patch is not in the cmake-3.8.1 ebuild, and that one doesn't > work. I take it the patch was integrated into mainline CMake for 3.9? It seems that both patches are only in cmake 3.9+, so we also need to apply those patches to 3.8.x. As both patches could be applied on top of 3.7 without changes, I guess they could also be applied on top of 3.8. Did you try adding those patches to the cmake-3.8.1 ebuild? Not yet. I don't have much time left to deal with the x32 device at the moment, so I'll stick with 3.7.2 for the time being, making sure it works properly for all the packages I have. For what it's worth, cmake-3.7.2-r10 managed to compile everything I threw at it (KF5, LXQt, etc.). So indeed it should also work if the patch is ported to 3.8 and with vanilla 3.9. *** Bug 595508 has been marked as a duplicate of this bug. *** *** Bug 602246 has been marked as a duplicate of this bug. *** *** Bug 615404 has been marked as a duplicate of this bug. *** The 3.9.0 RCs are in the tree (unkeyworded) which should fix this. I tried to test this but got hit by bug #624354. Might want to put that bug as a dependency of this one. But the patch indeed works as-is on CMake 3.8 without problems. 3.9.0 is in the tree now which should fix this. *** Bug 618084 has been marked as a duplicate of this bug. *** |