Created attachment 582126 [details, diff] Patch to cmake-utils.eclass to set CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX on riscv The CMake function find_library has some heuristics which can find libraries in e.g. /usr/lib64, but which can not handle the two level libdir of the riscv profiles. Thus, the suffix to append to "/usr/lib" etc needs to be hardcoded using the cmake variable CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX. The attached patch does just that, and with it I am able to emerge both cmake itself and dev-util/schroot, a package which uses cmake to build. Potentially the CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX could be set on all arches, but that would probably require much more testing.
I have no idea about riscv.
(In reply to Andreas Sturmlechner from comment #1) > I have no idea about riscv. Hi. Are you blocked on some information about riscv that you need? The libdir in the riscv profiles contain a second level with the ABI name, and as such are e.g. "lib64/lp64d", with the libraries placed under /usr/lib64/lp64d/. So there are no libraries directly under /usr/lib64/, and thus cmake's heuristic of looking for libs in /usr/lib64/ will not work. Using the CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX override to directly point out the correct libdir does work though.
@marcus, we'll have to send this as a patch to gentoo-dev for approval. Do we not need something similar for find_package()? pc files have the same issue.
You mean -config.cmake files, right? .pc files are for pkg-config, not cmake. But yes, it seems that we need to do something about find_package() as well. However, in this case it can't be fixed just with the eclass. cmFindLibraryCommand.cxx adds ${CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX} to the search list, but cmFindPackageCommand.cxx adds lib/${CMAKE_LIBRARY_ARCHITECTURE} (note the "lib/" first, where we need lib64/...) So a patch to cmake itself (can be upstreamed) is also needed.
As a tangential comment, I don't quite understand why the libdir is not lib/lp64d (which would work with the CMAKE_LIBRARY_ARCHITECTURE setting) rather than lib64/lp64d... Why do we need to specify "64" twice?
Created attachment 591974 [details, diff] Proposed patch to cmake for find_package() Since cmFindPackageCommand already uses FIND_LIBRARY_USE_LIB32_PATHS and FIND_LIBRARY_USE_LIB64_PATHS, I figured it would make sense for it to honour CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX as well. This way no additional change to the eclass is needed. I have tested that find_package(libxml2) works correctly with this patch (it didn't without).
(In reply to Marcus Comstedt from comment #6) > Created attachment 591974 [details, diff] [details, diff] > Proposed patch to cmake for find_package() > > Since cmFindPackageCommand already uses FIND_LIBRARY_USE_LIB32_PATHS and > FIND_LIBRARY_USE_LIB64_PATHS, I figured it would make sense for it to > honour CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX as well. This way no additional > change to the eclass is needed. > > I have tested that find_package(libxml2) works correctly with this patch > (it didn't without). I tested the patch with clang, and can confirm that it works. (In reply to Marcus Comstedt from comment #5) > As a tangential comment, I don't quite understand why the libdir is not > lib/lp64d (which would work with the CMAKE_LIBRARY_ARCHITECTURE setting) > rather than lib64/lp64d... Why do we need to specify "64" twice? """ In the new profiles, the lib->lib64 compatibility symlink is removed. 64-bit libraries need to be installed directly to lib64. /lib and /usr/lib become real directories, that are used for cross-arch and native non-library packages (gcc, clang) and 32-bit libraries on the multilib profile (which improves compatibility with prebuilt x86 packages). """ https://www.gentoo.org/support/news-items/2019-06-05-amd64-17-1-profiles-are-now-stable.html
(In reply to Göktürk Yüksek from comment #7) > 64-bit libraries need to be installed directly to lib64. Except that they aren't. They are installed in lib64/lp64d. So the letter of this rule is already violated. And I don't think installing them in lib/lp64d would go against the spirit of the rule (which is to not look for 64-bit libraries directly under lib).
(In reply to Marcus Comstedt from comment #8) > (In reply to Göktürk Yüksek from comment #7) > > > 64-bit libraries need to be installed directly to lib64. > > Except that they aren't. They are installed in lib64/lp64d. So the letter > of this rule is already violated. And I don't think installing them in > lib/lp64d would go against the spirit of the rule (which is to not look for > 64-bit libraries directly under lib). My understanding is that lib64/lp64{,d} is required to support multilib: https://www.sifive.com/blog/all-aboard-part-5-risc-v-multilib. If I have two variants of the same library, one supporting the ABI lp64 and another supporting lp64d, how would I keep them on the same machine without introducing path collisions?
By putting them in lib/lp64/ and lib/lp64d/ respectively. It's the need to put the 64-bit ABI directories under "lib64" rather than "lib" that I do not understand. It just ends up saying "64" twice...
(In reply to Marcus Comstedt from comment #10) > By putting them in lib/lp64/ and lib/lp64d/ respectively. It's the need to > put the 64-bit ABI directories under "lib64" rather than "lib" that I do not > understand. It just ends up saying "64" twice... I think it's there to prevent hypothetical problems of using the same ABI names on different bit-width architecture variants. Imagine that in the future we added support for rv32 and it also supports the lp64 ABI. And I want to compile a library targeting (rv32,lp64) and (rv64,lp64) configurations. If you were to put everything in lib/, you'd introduce a collision again. Obviously this is not a realistic scenario. The ABIs for rv32 and rv64 do not intersect. But I think the lib32/lib64 separation provides a more generic solution. Using the example above, you'd have lib32/lp64 and lib64/lp64 and there would be no collisions.
Yeah, that doesn't really make much sense. If the ABI:s are different they should not have the same name. And if the ABI:s are the same the library should be the same regardless of what hardware you run it on...
Note: The new "cmake.eclass" also needs to set CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX on riscv.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=89d746829c14ffb7ea1cc2de97bab63d0b77fdb5 commit 89d746829c14ffb7ea1cc2de97bab63d0b77fdb5 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2020-07-24 21:24:36 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2020-07-24 21:25:56 +0000 cmake*.eclass: Hardcode CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX for riscv Bug: https://bugs.gentoo.org/689410 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> eclass/cmake-utils.eclass | 6 ++++++ eclass/cmake.eclass | 6 ++++++ 2 files changed, 12 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=7318b8b9cfc9d2a172e75701ea95f63f7cffa0f5 commit 7318b8b9cfc9d2a172e75701ea95f63f7cffa0f5 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2020-07-24 21:24:36 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2020-07-24 21:29:04 +0000 cmake*.eclass: Hardcode CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX for riscv Bug: https://bugs.gentoo.org/689410 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> eclass/cmake.eclass | 6 ++++++ 1 file changed, 6 insertions(+)
Can we consider this fixed then?
