Using settings from /usr/lib64/gap/sysinfo.gap >>> Source configured. >>> Compiling source in /var/tmp/portage/dev-gap/cvec-2.8.1-r1/work/cvec-2.8.1 ... make -O -j4 V=1 "/usr/bin/gac" -d -p " -O2 -pipe -march=native -fno-diagnostics-color -O2 -pipe -march=native -fno-diagnostics-color" -P " -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0 " src/cvec.c -o bin/amd64/cvec.so x86_64-pc-linux-gnu-gcc -pthread -O2 -pipe -march=native -fno-diagnostics-color -fPIC -O2 -pipe -march=native -fno-diagnostics-color -O2 -pipe -march=native -fno-diagnostics-color -o /var/tmp/portage/dev-gap/cvec-2.8.1-r1/temp/gacVAEpDKm/29_cvec.o -I/usr/include/gap -I/usr/include -DUSE_GASMAN=1 -c src/cvec.c src/cvec.c:4234:5: error: initialization of struct OpaqueBag * (*)(void) from incompatible pointer type struct OpaqueBag * (*)(struct OpaqueBag *) [-Wincompatible-pointer-types] 4234 | TEST_ASSUMPTIONS, | ^~~~~~~~~~~~~~~~ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0-20241110-003003 UNMASKED: <sys-devel/gcc-15.0.9999:15 The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-15 * clang version 19.1.3 llvm-config: 19.1.3 Python 3.12.7 go version go1.23.2 linux/amd64 Available Ruby profiles: [1] ruby32 (with Rubygems) [2] ruby33 (with Rubygems) * Available Rust versions: [1] rust-bin-1.71.1 [2] rust-bin-1.77.1 [3] rust-bin-1.81.0 [4] rust-bin-1.82.0 [5] rust-1.82.0 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 11.0.25_p9 [openjdk-bin-11] 2) Eclipse Temurin JDK 17.0.13_p11 [openjdk-bin-17] *) Eclipse Temurin JDK 21.0.5_p11 [openjdk-bin-21] 4) Eclipse Temurin JDK 8.432_p06 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 [2] openjdk-bin-11 [3] openjdk-bin-17 [4] openjdk-bin-21 system-vm HEAD of ::gentoo commit 8566b21081f24b8ff8c5a8ecadbce83f2bdad484 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Mon Nov 18 17:03:30 2024 +0000 2024-11-18 17:03:29 UTC emerge -qpvO =dev-gap/cvec-2.8.1-r1 [ebuild N ] dev-gap/cvec-2.8.1-r1 USE="-examples -test"
Created attachment 909762 [details] emerge-info.txt
Created attachment 909763 [details] dev-gap:cvec-2.8.1-r1:20241118-221652.log
Created attachment 909764 [details] emerge-history.txt.xz
Created attachment 909765 [details] environment
Created attachment 909766 [details] etc.clang.tar.xz
Created attachment 909767 [details] etc.portage.tar.xz
Created attachment 909768 [details] logs.tar.xz
Created attachment 909769 [details] qlist-info.txt.xz
Created attachment 909770 [details] temp.tar.xz
Note that the change to -Werror=incompatible-pointer-types was in GCC 14. The issue here is that () vs (void) changes meaning in C23, as () now always means "no arguments" (same as (void)). -std=gnu23 becomes the default in GCC 15. Just that it's only an error because of that change we got made in 14 :)
Thanks, I updated the explanation upstream.
The root cause of this is some new incompatibility in the GAP function types: https://github.com/gap-system/gap/issues/5857 The short version is, GAP has a type called ObjFunc that takes any number of arguments and returns an Obj. (Extensions fill a struct with elements of this type to tell GAP which functions they provide.) In C17 and earlier, declaring ObjFunc with empty parentheses works fine, even when the actual functions may take arguments. In C23 of course, empty parens mean no arguments, and there's a build failure. OK, so we change it to (...). But both compilers now balk at passing a pointer to a function of e.g. one argument where a pointer to a function of a variable number of arguments is expected. Shouldn't foo(...) be a drop-in replacement for foo() under C23? It's pretty easy to reproduce this outside of GAP. The following works in C17 and earlier, but not C23. Pinging toolchain@ because I honestly don't know what to tell upstream besides maybe to add a million casts. #if ( __STDC_VERSION__ < 202300L ) // Works in C17 and earlier typedef int (* IntFunc)(); #else // Should work in C23? typedef int (* IntFunc)(...); #endif int run_it(IntFunc f) { return f(22); } int random_number(int x) { return 6; } int main(int argc, char** argv) { return run_it(random_number); }
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7652dc46d2b3e835f606dac9e7b7e87a5980175b commit 7652dc46d2b3e835f606dac9e7b7e87a5980175b Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2025-01-06 00:07:47 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2025-01-06 00:09:56 +0000 dev-gap/cvec: add 2.8.3, drop 2.8.2 Closes: https://bugs.gentoo.org/943925 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> dev-gap/cvec/Manifest | 2 +- dev-gap/cvec/{cvec-2.8.2.ebuild => cvec-2.8.3.ebuild} | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
(In reply to Michael Orlitzky from comment #12) I'm sorry for missing your question! > The short version is, GAP has a type called ObjFunc that takes any number of > arguments and returns an Obj. (Extensions fill a struct with elements of > this type to tell GAP which functions they provide.) Yes, you have to use ... for this now, BUT you have to use va_start/va_end with it (proper variadic args).
sudo had a similar problem in https://github.com/sudo-project/sudo/issues/420 which they chose a kind of poor/hacky solution for.
BTW, a gotcha I should mention just in general for C23, and I'll mention this on our wiki page now too: if a project has custom definitions of bool, swapping that out for _Bool/bool isn't safe unless that previous bool never appeared on an ABI boundary & wasn't serialised to disk, etc.
(In reply to Sam James from comment #14) > > Yes, you have to use ... for this now, BUT you have to use va_start/va_end > with it (proper variadic args). Any chance you could show me how you would fix the program in comment 12?
