Bug#1087562: pcre2: FTBFS on mips64el: ld: unrecognised emulation mode: elf

[Simon McVittie <smcv@debian.org>]

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-mips@lists.debian.org
User: debian-mips@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