On Mon, Feb 06, 2023 at 08:04:13PM +0100, Stephen Kitt wrote: > On Mon, 06 Feb 2023 17:53:31 +0200, Adrian Bunk <b...@debian.org> wrote: >... > > The RC severity is based on looking at a related question: > > How did intelrdfpmath compile on new platforms like powerpc/arm/s390x > > that never had any explicit support in intelrdfpmath? > > > > intelrdfpmath (2.0u2-2) unstable; urgency=medium > > * Assume unknown architectures are “EFI2”. > > > > LIBRARY/float128/architecture.h: > > #if defined(ct) || defined(efi2) > > # undef _M_AMD64 > > # define _M_AMD64 > > #endif > > > > This builds, but the (used) definition > > # define ENDIANESS little_endian > > isn't correct on s390x, and neither is > > # define BITS_PER_LONG 64 > > on 32bit arm. > > Ah, I knew that would bite me some day... > > I’m updating intelrdfpmath to apply the architecture definitions used in > libmongocrypt (see > <https://github.com/mongodb/libmongocrypt/blob/master/cmake/IntelDFP.cmake>): > armel/armhf are assumed to behave like i386 (I haven’t checked whether that > makes sense), arm64/ppc64el/riscv64 are assumed to behave like amd64, and > s390x is supported explicitly. > > If you want to track the unsupported architectures, please open a new bug. As > far as I can tell, even if libmongocrypt were built in Debian using its > embedded copy of intelrdfpmath, it would fail on the same architectures.
If arm64/ppc64el/riscv64 are assumed to behave like amd64 (little endian 64bit), and armel/armhf are assumed to behave like i386 (little endian 32bit), and s390x is big endian so clearly different, could you add mips64el and mipsel as little endian 64/32bit architectures there? This feels like the easiest way for getting the new version of libmongocrypt into bookworm. > Regards, > > Stephen Thanks Adrian
