On 13 Jul 2026, at 23:15, Simon McVittie <[email protected]> wrote: > > 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 > > 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?
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
