chmod +x ..//..//bin/amd64/execcmd.gap cp calcpres.gap ..//..//bin/amd64/calcpres.gap cc -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0 -Werror=lto-type-mismatch -Werror=strict-aliasing -Werror=odr -flto -o ..//..//bin/amd64/gprun gpd.o gpp.o permfns.o chmod +x ..//..//bin/amd64/calcpres.gap cc -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0 -Werror=lto-type-mismatch -Werror=strict-aliasing -Werror=odr -flto -o ..//..//bin/amd64/egrun egd.o egp.o permfns.o cc -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0 -Werror=lto-type-mismatch -Werror=strict-aliasing -Werror=odr -flto -o ..//..//bin/amd64/sylrun syld.o sylp.o morepermfns.o permfns.o gpd.c:68:7: error: type of gpprog does not match original declaration [-Werror=lto-type-mismatch] 68 | if (gpprog() == -1) | ^ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_desktop_gnome_systemd-20240924-072513 UNMASKED: Please re-assign to toolchain@ if you get a test failure in C, C++, or Fortran code which makes no sense. /etc/portage/package.unmask/60gcc:<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/llvm (if any): clang version 19.1.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/19/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/19 19.1.0 Python 3.12.6 Available Ruby profiles: [1] ruby32 * Available Rust versions: [1] rust-bin-1.81.0 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 17.0.12_p7 [openjdk-bin-17] *) Eclipse Temurin JDK 21.0.4_p7 [openjdk-bin-21] Available Java Virtual Machines: [1] openjdk-bin-17 [2] openjdk-bin-21 system-vm The Glorious Glasgow Haskell Compilation System, version 9.2.8 php cli (if any): go version go1.23.1 linux/amd64 HEAD of ::gentoo commit ec452dbe88b907bd2cb6b30a568598a52f9959ec Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Wed Sep 25 08:04:29 2024 +0000 2024-09-25 08:04:29 UTC emerge -qpvO =dev-gap/cohomolo-1.6.11 [ebuild N ] dev-gap/cohomolo-1.6.11 USE="-test"
Created attachment 903729 [details] emerge-info.txt
Created attachment 903730 [details] dev-gap:cohomolo-1.6.11:20240925-082614.log
Created attachment 903731 [details] emerge-history.txt
Created attachment 903732 [details] environment
Created attachment 903733 [details] etc.clang.tar.xz
Created attachment 903734 [details] etc.portage.tar.xz
Created attachment 903735 [details] qlist-info.txt
Created attachment 903736 [details] temp.tar.xz
This is known upstream and probably won't be fixed any time soon. I think I only added this because it's included in sage's optional gap_packages? Maybe nobody needs it and it can be removed. For now filter-lto seems like a good idea, but I wonder how to avoid build failures on the tinderbox. Append -Wno-error-* ?
CCing our local GAP expert. Is there a reason to keep cohomolo around?
(In reply to Michael Orlitzky from comment #9) > This is known upstream and probably won't be fixed any time soon. I think I > only added this because it's included in sage's optional gap_packages? Maybe > nobody needs it and it can be removed. > > For now filter-lto seems like a good idea, but I wonder how to avoid build > failures on the tinderbox. Append -Wno-error-* ? FWIW, filter-lto handles that for you for lto-type-mismatch because it can only be diagnosed at LTO-time. For aliasing issues, -fno-strict-aliasing should be passed. For ODR, filter-lto and pray. So just filter-lto should be OK here
please report upstream to https://github.com/gap-packages/cohomolo
(In reply to Dima Pasechnik from comment #12) > please report upstream to https://github.com/gap-packages/cohomolo It was reported upstream a year and a half ago at $URL :) Max's response was, Sure, there are lots of issues with this code base. It is legacy code, and in fact used to be K&R C until a few years ago. Would be great if someone spent the time to carefully update it. BTW one thing that makes this harder to resolve is that different files get linked together, and some genuinely use the same variable name for different things and with different types (e.g. space sometimes is an integer and sometimes an array); so one can't just blindly add all of these extern into a single header. No, one has to carefully identify which variables (of which type) are shared by which C files and then ideally add headers for each combo and move them there... To be clear, I won't work on any of these. I am more interested in modern re implementations of these algorithms. Interfacing to this ancient C code via shell scripts is not the best model going forward :-)
After inspection, no other gap package seem to depend on it which makes it ripe for deletion. But I would be more confident if upstream did the move too. At this point the C code is abandonware unless someone step up (not me).
