Source: pcre2 Version: 10.44-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-m...@lists.debian.org User: debian-m...@lists.debian.org Usertags: mips64el
This looks like it might be a problem with some toolchain component (but I don't know which one), so please reassign and set "affects" on src:pcre2 as appropriate. pcre2's build system seems to have somehow got the idea that `/usr/bin/ld -m elf` is the correct linker, for whatever reason (I don't know where this is coming from, I can't find it hard-coded in pcre2 or in libtool). But that is not a mode that works on mips64el: https://buildd.debian.org/status/fetch.php?pkg=pcre2&arch=mips64el&ver=10.44-2&stamp=1731663153&raw=0 > checking if the linker (/usr/bin/ld) is GNU ld... yes ... > checking whether the gcc linker (/usr/bin/ld -m elf) supports shared > libraries... /usr/bin/ld: unrecognised emulation mode: elf > Supported emulations: elf64ltsmip elf64btsmip elf32ltsmipn32 elf32btsmipn32 > elf32ltsmip elf32btsmip > no and as a result it unintentionally builds the libpcre2* family of libraries as static-only, resulting in incomplete binary packages: > libtool: install: /usr/bin/install -c .libs/libpcre2-posix.lai > /<<PKGBUILDDIR>>/debian/tmp/usr/lib/mips64el-linux-gnuabi64/libpcre2-posix.la ... > libtool: install: /usr/bin/install -c .libs/libpcre2-posix.a > /<<PKGBUILDDIR>>/debian/tmp/usr/lib/mips64el-linux-gnuabi64/libpcre2-posix.a > libtool: install: chmod 644 > /<<PKGBUILDDIR>>/debian/tmp/usr/lib/mips64el-linux-gnuabi64/libpcre2-posix.a > libtool: install: ranlib > /<<PKGBUILDDIR>>/debian/tmp/usr/lib/mips64el-linux-gnuabi64/libpcre2-posix.a ... > dh_install: warning: libpcre2-posix3 missing files: > debian/tmp/usr/lib/*/libpcre2-posix.so.* ... > dh_install: error: missing files, aborting The same new upstream release of pcre2 failed in the same way in experimental on 2024-11-08, so I'm surprised that it was re-uploaded to unstable without checking experimental buildd logs for a successful build. The most recent successful build of pcre2 was 10.43-1 back in February, which used "ld -m elf64ltsmip". util-linux is an example of an Autotools package that was uploaded to unstable more recently (2024-11-03) and it also used "ld -m elf64ltsmip". I see two possibilities for the cause of this bug: 1. there is something different about pcre2 that causes detection of the correct ld mode to fail; or 2. some dependency changed between 2024-11-03 and now Perhaps someone who is better at toolchains than me can figure this out? Thanks, smcv
