Bug#1142020: libffi: FTBFS on armhf,i386,hppa,m68k,sh4,sparc64: (symver)LIBFFI_INT128_8.3 disappeared from the symbols file

On 13 Jul 2026, at 23:15, Simon McVittie <[email protected]> wrote:
>=20
> 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: [email protected], =
[email protected], [email protected], =
[email protected], [email protected]
> User: [email protected]
> Usertags: armhf
> User: [email protected]
> Usertags: hppa
> User: [email protected]
> Usertags: m68k
> User: [email protected]
> Usertags: sh4
> User: [email protected]
> Usertags: sparc64
> User: [email protected]
> Usertags: i386
>=20
> The recent libffi upload didn't build successfully on armhf, i386 and=20=

> several -ports architectures. =46rom the buildd log=20
> =
https://buildd.debian.org/status/fetch.php?pkg=3Dlibffi&arch=3Darmhf&ver=3D=
3.7.1-1&stamp=3D1783944369&raw=3D0=20
> and other architectures:
>=20
> 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=3D!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=3D!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
>=20
> Perhaps this means the affected architectures don't offer an int128=20
> type in their ABIs? They are mostly, but not entirely, 32-bit (sparc64=20=

> is 64-bit).
>=20
> If libffi is expected to need per-architecture symbols file =
adjustments,=20
> it might be a good idea to do the initial upload of each new upstream=20=

> release to experimental, to avoid multiarch skew in unstable?

32-bit architectures don=E2=80=99t 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=E2=80=99t 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=E2=80=99s about =
whether
that architecture=E2=80=99s 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