C++ -O2 -pipe -march=native -fno-diagnostics-color -std=c++14 -Wall -pedantic Linker flags: Executable -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 Module -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 Shared -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -- Configuring incomplete, errors occurred! * ERROR: net-im/openmittsu-0.10.0.0::gentoo failed (configure phase): * cmake failed ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_plasma_systemd-j5_test-20230603-114005 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-10 [2] x86_64-pc-linux-gnu-13 * clang/llvm (if any): clang version 16.0.5 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/16/bin Configuration file: /etc/clang/clang.cfg /usr/lib/llvm/16 16.0.5 Python 3.11.3 Available Ruby profiles: [1] ruby31 (with Rubygems) * Available Rust versions: [1] rust-bin-1.69.0 * The following VMs are available for generation-2: *) Eclipse Temurin JDK 17.0.6_p10 [openjdk-bin-17] Available Java Virtual Machines: [1] openjdk-bin-17 system-vm php cli (if any): go version go1.20.4 linux/amd64 HEAD of ::gentoo commit 7b93a7df86f01133956712a3ab386bfaf4fc441d Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sun Jun 4 21:47:51 2023 +0000 2023-06-04 21:47:51 UTC emerge -qpvO net-im/openmittsu [ebuild N ] net-im/openmittsu-0.10.0.0 USE="test"
Created attachment 863276 [details] emerge-info.txt
Created attachment 863277 [details] CMakeCache.txt
Created attachment 863278 [details] emerge-history.txt
Created attachment 863279 [details] environment
Created attachment 863280 [details] etc.clang.tar.xz
Created attachment 863281 [details] etc.portage.tar.xz
Created attachment 863282 [details] net-im:openmittsu-0.10.0.0:20230604-225528.log
Created attachment 863283 [details] temp.tar.xz
The problem is due to cmake.eclass changing CMAKE_BUILD_TYPE from "Gentoo" to "RelWithDebInfo" (why?). I've added an explicit CMAKE_BUILD_TYPE="Gentoo" to the ebuild which should fix the problem.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a25da7af195434ae468a4073ea6530662bad1212 commit a25da7af195434ae468a4073ea6530662bad1212 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2023-06-05 09:45:58 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2023-06-05 09:48:05 +0000 net-im/openmittsu: Set CMAKE_BUILD_TYPE The default changed in cmake.eclass for EAPI 8, breaking the upstream build system. Closes: https://bugs.gentoo.org/907866 Signed-off-by: Ulrich Müller <ulm@gentoo.org> net-im/openmittsu/openmittsu-0.10.0.0.ebuild | 2 ++ 1 file changed, 2 insertions(+)
(In reply to Ulrich Müller from comment #9) > The problem is due to cmake.eclass changing CMAKE_BUILD_TYPE from "Gentoo" > to "RelWithDebInfo" (why?). I'm more wondering why upstream is being made to have custom rules for Gentoo. That build type was just for private eclass use and was changed because it's non-standard and caused more troubles than it fixed.
(In reply to Ionen Wolkens from comment #11) > (In reply to Ulrich Müller from comment #9) > > The problem is due to cmake.eclass changing CMAKE_BUILD_TYPE from "Gentoo" > > to "RelWithDebInfo" (why?). > I'm more wondering why upstream is being made to have custom rules for > Gentoo. i.e. it makes more sense to have an option like -DSKIP_THING=1 than "skip if it's gentoo"
(In reply to Ionen Wolkens from comment #11) > (In reply to Ulrich Müller from comment #9) > > The problem is due to cmake.eclass changing CMAKE_BUILD_TYPE from "Gentoo" > > to "RelWithDebInfo" (why?). > I'm more wondering why upstream is being made to have custom rules for > Gentoo. > > That build type was just for private eclass use and was changed because it's > non-standard and caused more troubles than it fixed. I had discussed this with one of the maintainers of cmake.eclass (unfortunately, I cannot find the log) and the advice back then was that testing CMAKE_BUILD_TYPE was the way to go. So, I don't think it makes much sense if I reiterate this with upstream. (If any of the eclass maintainers wants to do it, feel free.) Also, looks like the default set by cmake{-utils,}.eclass has changed several times, from "Release" to "None" to "Gentoo" to "RelWithDebInfo". (Why "DebInfo"? What if the user has -g0 in CFLAGS, shouldn't that be honoured?)
