Debian Patches

Status for gfan/0.8~beta-4

Patch Description Author Forwarded Bugs Origin Last update
compile-on-more-systems.patch Build gfan on a wider variety of systems Gfan 0.8beta builds only on a fairly narrow set of toolchains. This patch
collects the changes needed to build it with the system compiler on macOS,
with clang, and with the compilers shipped by older distributions, back to
GCC 7.5 on Ubuntu 18.04 and GCC 8.5 on RHEL 8. It adds no dependency:
gfan already links TBB unconditionally, and the memory_resource fallback
uses what libstdc++ has shipped since GCC 6.
.
Parallelism: gfan drove its parallel loops through std::for_each with
std::execution::par. libc++ has no <execution> at all and libstdc++ only
gained it in GCC 9; where it does exist it is implemented on top of TBB.
Call TBB directly. That also removes the reason for the include-ordering
workaround at the top of log.h, which pulled <execution> into all 110
translation units that include it, and it exposes two files that had been
getting <atomic> through that include. Two loops are deliberately left
sequential: they walk a std::set, so libstdc++ never parallelised them,
and their body writes to std::cout unlocked and names output files after
an index that is not unique across threads.
.
Library features that are too new: <semaphore> (GCC 11, Xcode 14) was
needed only by unreachable scratch code, which is removed; std::erase_if
and std::filesystem each had one call site and are replaced with older
equivalents; and std::pmr, which is threaded through the core matrix and
vector types, falls back to <experimental/memory_resource>, the Library
Fundamentals TS version that std::pmr came from.
.
Language features that are too new: operator!= was left to the C++20
rewritten candidate for operator==, which GCC 9 does not synthesise, and a
multimap was left to default construct a lambda comparator, which is only
possible from C++20. With those gone, gfan compiles as C++17, so the
hardcoded -std=c++20 becomes -std=c++17; GCC 9 spells that standard c++2a
and GCC 7 does not have it at all.
.
Makefile: the macOS pin to gcc-15/g++-15 is gone, so macOS uses its own
compiler; a -fno-guess-branch-probability workaround for a gcc 4.7.2 bug
goes with it, since clang rejects the option; and -march=native is no
longer passed unconditionally, which clang rejects outright on arm64 and
which otherwise leaves a binary tuned for whichever machine compiled it.
The existing vectorize= switch, which previously set the same value in
both of its branches, now turns it back on.
.
One change is not a build fix but was made along the way: virtual
destructors for EnumerationTarget and EnumerationAlgorithm, which are
deleted through base class pointers.
.
Verified by building and running the gfan test suite (50/50) on Ubuntu
18.04, 20.04, 22.04, 24.04 and 25.04 (GCC 7.5 through 14.2), Rocky Linux
8 (GCC 8.5), macOS 26 on arm64, and with clang.

diff --git a/Makefile b/Makefile
index 1d5fad9..e64e65d 100644		 Claude Opus 5 <noreply@anthropic.com> invalid 2026-08-13
fix_spelling_errors.patch Doug Torrance <dtorrance@debian.org> invalid 2020-11-13
remove_failing_tests_on_32bits.patch remove 0009RenderStairCase tests This test fails on 32 bit architectures, causing the build to fail Cédric Boutillier <boutil@debian.org> no debian 2018-06-27
fix_other_warnings_clang.diff fix some warnings emmitted by clang - typo in macro
- type warning in format strings		 Cédric Boutillier <boutil@debian.org> invalid 2020-11-13
make_tests_return_error.patch Nonzero return code if tests fail invalid https://git.sagemath.org/sage.git/commit/build/pkgs/gfan/patches/maketestsreturnerror.patch?h=develop&id=4ad830c4cbb10ce81d49eb92cbd3b1be2df31e7b 2020-11-13
int128.patch Use 128-bit integers from Abseil when not available natively. Doug Torrance <dtorrance@debian.org> no 2024-10-24
link-libatomic.patch Link against libatomic where required Some architectures (e.g. powerpc and sh4) do not provide lock-free 64-bit
atomics inline and instead emit calls into libatomic, resulting in undefined
references such as __atomic_fetch_add_8 at link time. Since gfan does not use
autoconf, probe for this in the Makefile: try to link a small program using a
64-bit atomic without -latomic, and only add the flag when that fails but
succeeds with -latomic. On architectures with inline atomics (e.g. amd64,
arm64) no extra library is linked.		 Claude Opus 4.8 <noreply@anthropic.com> no 2026-07-12

All known versions for source package 'gfan'

Links