Created attachment 650154 [details] build.log while emerging google-cloud-cpp Cmake determines ${libdir} with the plugin GNUInstallDirs. It will detect the existence of '/etc/debian_version' and '/etc/arch-release' and then set ${libdir} release-specifically. For instance, if '/etc/debian_version' exists, cmake will set ${libdir} to 'lib', other than 'lib64'. If one happened to bootstrap a Gentoo Prefix inside a Debian Linux, cmake could set a wrong value to ${libdir} since "/etc/debian_version" exists. So in my Debian-based Gentoo Prefix, the behavior described above causes problem while building google-cloud-cpp::gentoo, as the attachment below. Since it turns out that this problem is introduced by cmake, I believe it will be better to patch cmake than to patch google-cloud-cpp. Currently, I stopped cmake from detecting '/etc/debian_version' by patching the source code, and It works fine now. The patches are attached below.
Created attachment 650156 [details] emerge --info
Created attachment 650158 [details, diff] a patch that I am using now
Reproduced by `touch /etc/debian_version`.
Is >=dev-util/cmake-3.14 no longer masked for prefix?
Created attachment 650206 [details, diff] cmake-3.17.3-no-platform-detect.patch Thanks for your patch, that gave me some pointers. I went a slightly different route.
(In reply to Andreas Sturmlechner from comment #4) > Is >=dev-util/cmake-3.14 no longer masked for prefix? I think it is not masked now, since there is no related string in my '${EPREFIX}/etc/portage/package.unmask'. (In reply to Andreas Sturmlechner from comment #5) > Created attachment 650206 [details, diff] [details, diff] > cmake-3.17.3-no-platform-detect.patch > > Thanks for your patch, that gave me some pointers. I went a slightly > different route. Glad to help :)
(In reply to ZongyuZ from comment #6) > Glad to help :) Please note that net-libs/google-cloud-cpp is EAPI-6 and using deprecated cmake-utils.eclass, the fix in the linked PR is only going to be in cmake.eclass once approved. That means for testing you should find an EAPI-7/cmake.eclass-based package.
By the sound of it, this could also have an impact on bug 702048.
Thank you for all the work sorting this through. I would like to have it carried in Gentoo at the same time we push it upstream.
cmake 3.20.0 even fails at configure phase. The upstream closed the merge request but haven't merge it yet. Meanwhile I found an alternative workaround: https://github.com/gentoo/gentoo/pull/20274.
Created attachment 697842 [details] build log using cmake-3.20.0
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8e5e1f3ef263363ec0426ce7a8a3dec6f5f5bb5d commit 8e5e1f3ef263363ec0426ce7a8a3dec6f5f5bb5d Author: Benda Xu <heroxbd@gentoo.org> AuthorDate: 2021-07-15 16:48:22 +0000 Commit: Benda Xu <heroxbd@gentoo.org> CommitDate: 2021-07-15 16:53:17 +0000 p/f/prefix/standalone/profile.bashrc: remove Debian magic. We are Gentoo, and we unconditionally turn off Debian related tests. The upstreaming process has stalled and we work around this bug by hacking the profile. Remove this when upstream figure out how to deal with distributions. Reference: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5047 Reference: https://gitlab.kitware.com/cmake/cmake/-/issues/18979 Bug: https://bugs.gentoo.org/733480 Closes: https://bugs.gentoo.org/757006 Closes: https://github.com/gentoo/gentoo/pull/20274 Signed-off-by: Benda Xu <heroxbd@gentoo.org> profiles/features/prefix/standalone/profile.bashrc | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
