compiling ebmldate.c compiling ebmlelement.c compiling ebmlmain.c compiling ebmlmaster.c ebmlmaster.c:149:39: error: incompatible function pointer types passing 'int (const ebml_element *, const ebml_element **, const ebml_element **)' (aka 'int (const struct ebml_element *, const struct ebml_element **, const ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_hardened-j4-20221110-130010 ------------------------------------------------------------------- CC=clang CXX=clang++ gcc-config -l: [1] x86_64-pc-linux-gnu-12 * clang/llvm (if any): clang version 15.0.4 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/15/bin Configuration file: /etc/clang/clang.cfg /usr/lib/llvm/15 15.0.4 Python 3.10.8 Available Ruby profiles: [1] ruby31 * Available Rust versions: [1] rust-bin-1.65.0 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 17.0.4.1_p1 [openjdk-bin-17] *) Eclipse Temurin JDK 8.345_p01 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm [2] openjdk-bin-17 The Glorious Glasgow Haskell Compilation System, version 9.0.2 php cli (if any): HEAD of ::gentoo commit 69f0b7550ab587381bffca4687249bd3f505afdf Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Fri Nov 11 10:16:50 2022 +0000 2022-11-11 10:16:50 UTC emerge -qpvO media-video/mkclean [ebuild N ] media-video/mkclean-0.8.10
Created attachment 831017 [details] emerge-info.txt
Created attachment 831019 [details] emerge-history.txt
Created attachment 831021 [details] environment
Created attachment 831023 [details] etc.clang.tar.bz2
Created attachment 831025 [details] etc.portage.tar.bz2
Created attachment 831027 [details] media-video:mkclean-0.8.10:20221111-110812.log
Created attachment 831029 [details] temp.tar.bz2
Created attachment 831031 [details] var.tmp.clang.tar.bz2
Appears to be fixed upstream by updating to the next version.
ci has reproduced this issue with version 0.8.10-r1 - Updating summary.
Also gcc can't compile mkclean bug exists since two years. If package is broken why gentoo still keep it in tree? Please fix it or remove, it's frustrating to trying install packaga that is known that is broken on gentoo.
(In reply to Marcin Mirosław from comment #11) > Also gcc can't compile mkclean bug exists since two years. If package is > broken why gentoo still keep it in tree? Please fix it or remove, it's > frustrating to trying install packaga that is known that is broken on gentoo. It's slightly more subtle than that. This was a research bug because we knew that GCC 14 would cause this to become an error, and we spent several years tracking down package that would be broken. GCC 14 was finally released and stabilized to Gentoo users on November 20, just 3 months ago. The package compiles "fine" with GCC 13. This package is one of the unmaintained packages that lagged behind. You can certainly say that it is broken though. :)
Now it looks better if package doesn't compile only since gcc-14. So... the most "stupid" workarround is add build/compile(r) depend to package gcc<14 but meseems that ebuild can't force different version of gcc that is choosen by gcc-config. Thanks for reply.
