Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 733480 - dev-utils/cmake does not determine ${libdir} gracefully, and is not suitable for Gentoo Prefix
Summary: dev-utils/cmake does not determine ${libdir} gracefully, and is not suitable ...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo KDE team
Keywords: PullRequest
Depends on:
Blocks: 757006
  Show dependency tree
Reported: 2020-07-22 07:10 UTC by ZongyuZ
Modified: 2021-07-15 16:53 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---

build.log while emerging google-cloud-cpp (,197.91 KB, text/x-log)
2020-07-22 07:10 UTC, ZongyuZ
emerge --info (emerge-info,5.69 KB, text/plain)
2020-07-22 07:11 UTC, ZongyuZ
a patch that I am using now (cmake-3.17.3-stop-from-detecting-release-type.patch,6.52 KB, patch)
2020-07-22 07:19 UTC, ZongyuZ
Details | Diff
cmake-3.17.3-no-platform-detect.patch (cmake-3.17.3-no-platform-detect.patch,14.56 KB, patch)
2020-07-22 14:39 UTC, Andreas Sturmlechner
Details | Diff
build log using cmake-3.20.0 (build_with_cmake-3.20.0.log,8.77 KB, application/octet-stream)
2021-04-06 03:08 UTC, Yiyang Wu

Note You need to log in before you can comment on or make changes to this bug.
Description ZongyuZ 2020-07-22 07:10:37 UTC
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.
Comment 1 ZongyuZ 2020-07-22 07:11:11 UTC
Created attachment 650156 [details]
emerge --info
Comment 2 ZongyuZ 2020-07-22 07:19:14 UTC
Created attachment 650158 [details, diff]
a patch that I am using now
Comment 3 Andreas Sturmlechner gentoo-dev 2020-07-22 14:26:52 UTC
Reproduced by `touch /etc/debian_version`.
Comment 4 Andreas Sturmlechner gentoo-dev 2020-07-22 14:31:46 UTC
Is >=dev-util/cmake-3.14 no longer masked for prefix?
Comment 5 Andreas Sturmlechner gentoo-dev 2020-07-22 14:39:19 UTC
Created attachment 650206 [details, diff]

Thanks for your patch, that gave me some pointers. I went a slightly different route.
Comment 6 ZongyuZ 2020-07-22 14:49:58 UTC
(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 :)
Comment 7 Andreas Sturmlechner gentoo-dev 2020-07-22 15:05:40 UTC
(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.
Comment 8 Andreas Sturmlechner gentoo-dev 2020-07-22 15:34:56 UTC
By the sound of it, this could also have an impact on bug 702048.
Comment 9 Benda Xu gentoo-dev 2021-01-08 08:59:16 UTC
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.
Comment 10 Yiyang Wu 2021-04-06 03:03:14 UTC
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:
Comment 11 Yiyang Wu 2021-04-06 03:08:09 UTC
Created attachment 697842 [details]
build log using cmake-3.20.0
Comment 12 Larry the Git Cow gentoo-dev 2021-07-15 16:53:38 UTC
The bug has been referenced in the following commit(s):

commit 8e5e1f3ef263363ec0426ce7a8a3dec6f5f5bb5d
Author:     Benda Xu <>
AuthorDate: 2021-07-15 16:48:22 +0000
Commit:     Benda Xu <>
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.
    Signed-off-by: Benda Xu <>

 profiles/features/prefix/standalone/profile.bashrc | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)