Source: libffi
Version: 3.7.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-68k@lists.debian.org, debian-arm@lists.debian.org, debian-hppa@lists.debian.org, debian-sparc@lists.debian.org, debian-superh@lists.debian.org
User: debian-arm@lists.debian.org
Usertags: armhf
User: debian-hppa@lists.debian.org
Usertags: hppa
User: debian-68k@lists.debian.org
Usertags: m68k
User: debian-superh@lists.debian.org
Usertags: sh4
User: debian-sparc@lists.debian.org
Usertags: sparc64
User: debian-qa@lists.debian.org
Usertags: i386

The recent libffi upload didn't build successfully on armhf, i386 and
several -ports architectures. From the buildd log
https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=armhf&ver=3.7.1-1&stamp=1783944369&raw=0
and other architectures:

dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
dpkg-gensymbols: warning: debian/libffi8/DEBIAN/symbols does not match completely debian/libffi8.symbols
--- debian/libffi8.symbols (libffi8_3.7.1-1_armhf)
+++ dpkg-gensymbolsJgDtu7	2026-07-13 12:06:07.296266272 +0000
@@ -5,4 +5,4 @@
  (symver)LIBFFI_CLOSURE_8.0 3.4
  (symver|arch=!arc !hppa !ia64 !m68k !loong64 !any-mips !any-mipsel !any-mips64 !nios2 !powerpc !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_8.0 3.4
  (symver|arch=!arc !hppa !ia64 !m68k !nios2 !sh4)LIBFFI_GO_CLOSURE_8.0 3.4
- (symver)LIBFFI_INT128_8.3 3.7
+#MISSING: 3.7.1-1# (symver)LIBFFI_INT128_8.3 3.7

Perhaps this means the affected architectures don't offer an int128
type in their ABIs? They are mostly, but not entirely, 32-bit (sparc64
is 64-bit).

If libffi is expected to need per-architecture symbols file adjustments,
it might be a good idea to do the initial upload of each new upstream
release to experimental, to avoid multiarch skew in unstable?

Thanks,
    smcv

32-bit architectures don’t have __int128, so those are expected.

sparc64 is unexpected, but uses libcalls for it, so probably some
configure script check is a bit broken and gives a false negative.

ppc64el is also missing the symbol, along with others, but not in your
list here, and I assume the same is true for ppc64 but the build log is
missing. That one doesn’t use libcalls, which is stranger, so maybe
something else is going on here.

And looking through the source, the uses of this symbol version are
gated on FFI_TARGET_HAS_INT128. So, yes, being an architecture that
supports __int128 is necessary, but not sufficient. It’s about whether
that architecture’s ABI needs to consider __int128 or not (which will
of course imply that type is supported!). Searching the source for the
macro that list is:

alpha
amd64
arm64
loong64
riscv64
s390x
x32

Which is indeed the exact set of architectures it successfully built
for.

Jessica

Version: 3.7.1-2
[...]

Appears to have been fixed by:

libffi (3.7.1-2) unstable; urgency=medium

   * Conditionalize new symbols on architectures.