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? Thanks, smcv
