CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (project) ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop-libressl-20200826-071836 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.1 [2] x86_64-pc-linux-gnu-10.2.0 * clang version 10.0.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/10/bin /usr/lib/llvm/10 10.0.1 Available Python interpreters, in order of preference: [1] python3.7 [2] python3.9 (fallback) [3] python3.8 (fallback) [4] python3.6 (fallback) [5] python2.7 (fallback) [6] pypy3 (fallback) Available Ruby profiles: [1] ruby25 (with Rubygems) * Available Rust versions: [1] rust-bin-1.46.0 [2] rust-1.46.0 * The following VMs are available for generation-2: *) IcedTea JDK 3.16.0 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.8.4 timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Thu Sep 3 12:05:36 PM UTC 2020 /var/db/repos/libressl Tue Sep 1 07:07:28 PM UTC 2020 emerge -qpvO gnustep-base/libobjc2 [ebuild N ] gnustep-base/libobjc2-2.1 USE="-boehm-gc -test"
this seems to be either still an issue or a similarity to the one reported in bug 710888
Created attachment 658142 [details] emerge-info.txt
Created attachment 658144 [details] CMakeError.log
Created attachment 658146 [details] CMakeOutput.log
Created attachment 658148 [details] emerge-history.txt
Created attachment 658150 [details] environment
Created attachment 658152 [details] etc.portage.tbz2
Created attachment 658154 [details] gnustep-base:libobjc2-2.1:20200903-130821.log
Created attachment 658156 [details] logs.tbz2
Created attachment 658158 [details] temp.tbz2
Oh I may have closed bug #710888 too fast then, strange as it runs fine here (and tested multiple times for other fixes). Let me take a look
@Toralf, this package only builds with (and forces) clang, but it does not look like it supports the new gcc flag style you have in this run: clang -falign-functions=32:25:16 test.c -o a clang-10: error: invalid integral value '32:25:16' in '-falign-functions=32:25:16' I am not sure how to protect the ebuild run though, should we filter this flag?
*** This bug has been marked as a duplicate of bug 873988 ***