CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:12 (project) ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 13.0-desktop-plasma_libressl_20170806-123532 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.4.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python3.6 (fallback) [3] python2.7 (fallback) java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.5.1 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm emerge -qpv sys-libs/compiler-rt [ebuild N ] sys-libs/compiler-rt-4.0.1 USE="clang {test}"
Created attachment 488528 [details] emerge-info.txt
Created attachment 488530 [details] CMakeError.log
Created attachment 488532 [details] CMakeOutput.log
Created attachment 488534 [details] emerge-history.txt
Created attachment 488536 [details] environment
Created attachment 488538 [details] etc.portage.tbz2
Created attachment 488540 [details] logs.tbz2
Created attachment 488542 [details] sys-libs:compiler-rt-4.0.1:20170809-212900.log
Created attachment 488544 [details] temp.tbz2
Same for me. But the weird thing: At first this ebuild was compiling but then broke when 1. upgrading to: glibc-2.25-r2 gcc-6.4.0 binutils-2.28.1 2. rebuild of all libs and @system and llvm/clang, all went through but: Fact is: I have an installed sys-libs/compiler-rt-4.0.1 but cannot rebuild that specific ebuild: errors out like @Toralf
(In reply to Ulenrich from comment #10) > Same for me. But the weird thing: > At first this ebuild was compiling but then broke when > 1. upgrading to: glibc-2.25-r2 gcc-6.4.0 binutils-2.28.1 > 2. rebuild of all libs and @system and llvm/clang, all went through but: > > Fact is: > I have an installed sys-libs/compiler-rt-4.0.1 > but cannot rebuild that specific ebuild: > errors out like @Toralf I have the same trouble with glibc-2.25-r2 gcc-5.4.0-r3 binutils-2.28.1. Last successful compilation was 30.06.2017.
I have no clue why it suddenly started failing. I can reproduce the failure even on my test chroot which is severely outdated: sys-libs/glibc 2.23-r3 sys-devel/gcc 4.9.4 sys-devel/binutils 2.25.1-r1 So it's rather unrelated to system upgrades. And since the same version used to build fine, it's not something in compiler-rt either.
It's the flag stripping not working properly for some reason. I'm going to revert that for now. commit 0e6d20439e89c82fa99bbaefbe2a728efc77631c Author: Michał Górny <mgorny@gentoo.org> Date: Sat Jul 1 18:14:44 2017 flag-o-matic.eclass: Strip LDFLAGS unsupported by the C compiler, #621274 Include LDFLAGS in the variables stripped by strip-unsupported-flags. The code reuses the current functions for testing CC, and so only remove LDFLAGS that are rejected by the C compiler and not the linker. This solves the case of bug #621274 where LDFLAGS contained GCC-specific -flto flag.
commit 28dd7e772d7245723a725ea13673b3419139cd43 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Fri Aug 11 16:33:18 2017 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Fri Aug 11 16:35:09 2017 flag-o-matic.eclass: Revert "Strip LDFLAGS unsupported by the C..." The current logic strips too much, causing build failures. Revert it until we get it right. Bug: https://bugs.gentoo.org/627474
@Michał Górny very thanks Compiles now again. My gosh - there are kind of bugs: I was caught in a bigger upgrade and then naturally thinking about having done it using unstable gcc~ and glibc~ Now, having solved the last and only problem recompiling my system, I must say Gentoo~unstable works reliable for me again and again after all those years :)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ddba1d149e82dba88b72f992729ad4158f640e32 commit ddba1d149e82dba88b72f992729ad4158f640e32 Author: Alexander Miller <alex.miller@gmx.de> AuthorDate: 2022-08-07 01:34:33 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-08-24 04:55:53 +0000 flag-o-matic.eclass: test-flag-PROG, strip unused args that generate warnings A number of configure checks used by CMake and autoconf (and probably other build systems) relies on warning-free compiler runs. A combination of compiler and flags that always generates warnings can cause misconfiguration and/or build failures. Since commit ae9870d9f6b1394ede86176443770b36d7e60ac1, flags that generate warnings that could be suppressed with -Qunused-arguments are accepted anyway to avoid stripping all linker flags (#627474). But commit 28d6437fc7009002f98f28e8900e994109927726 added linker invocation for linker flags tests, so the workaround shouldn't be necessary any more. Drop the extra -Qunused-arguments check and reject all flags that generate warnings to avoid configuration issues. If it turns out that stripping these unused flags is still problematic, we could accept them and actually add -Qunused-arguments to the relevant *FLAGS to silence the warnings, but that would require bigger changes, so let's try the simpler and cleaner solution first. Bug: https://bugs.gentoo.org/627474 Bug: https://bugs.gentoo.org/714742 Bug: https://bugs.gentoo.org/862798 Signed-off-by: Alexander Miller <alex.miller@gmx.de> Closes: https://github.com/gentoo/gentoo/pull/26773 Signed-off-by: Sam James <sam@gentoo.org> eclass/flag-o-matic.eclass | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
