- Package:
- src:intelrdfpmath
- Source:
- src:intelrdfpmath
- Submitter:
- Adrian Bunk
- Date:
- 2023-02-13 12:24:03 UTC
- Severity:
- normal
- Tags:
intelrdfpmath FTBFS on the older platforms alpha/hppa/mips where it seems to used to have support for, but that support is now so broken that even the headers necessary for compilation are missing: float128/dpml_exception.h:315:17: fatal error: alpha_linux_exception.h: No such file or directory 315 | # include "alpha_linux_exception.h" float128/dpml_private.h:215:14: fatal error: mips_macros.h: No such file or directory 215 | # include "mips_macros.h" (The hppa FTBFS looks different, I haven't checked whether that's also related to the stale hp_pa code.) This is a problem for libmongocrypt, which started to use intelrdfpmath but whose new version is currently blocked from testing migration due to libintelrdfpmath-dev not being available on mipsel/mips64el. 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.
I’m afraid there isn’t much I can do about that, other than ask upstream to add MIPS support. Given the RC severity of this bug, I’ll consider the main point of the bug to be the latter part: 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. Regards, Stephen
I’m afraid there isn’t much I can do about that, other than ask upstream to add MIPS support. Given the RC severity of this bug, I’ll consider the main point of the bug to be the latter part: 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. Regards, Stephen
Hello, Bug #1030701 in intelrdfpmath reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/intelrdfpmath/-/commit/55fe834e7528943d0307f5473fa9b205f24644cf ------------------------------------------------------------------------ Fix architecture support on non-x86 Closes: #1030701 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1030701
So, based on the fact that upstream treats x86 and x86_64 as having the same data model, I came up with the attached patch. It allows the build to succeed on both mips64el and mipsel. I am preparing to test (using the libmongocrypt tests as a proxy) and I will report back with the results of those tests. Regards,
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. Thanks Adrian
We believe that the bug you reported is fixed in the latest version of
intelrdfpmath, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1030701@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Stephen Kitt <skitt@debian.org> (supplier of updated intelrdfpmath package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 06 Feb 2023 20:09:18 +0100
Source: intelrdfpmath
Architecture: source
Version: 2.0u2-7
Distribution: unstable
Urgency: medium
Maintainer: Christian Stalp <chris@chrishell.de>
Changed-By: Stephen Kitt <skitt@debian.org>
Closes: 1030701
Changes:
intelrdfpmath (2.0u2-7) unstable; urgency=medium
.
* Stop pretending that all non-explicitly supported architectures are
equivalent to amd64 (which is what “EFI2” is in this library).
Instead, apply the definitions used in libmongocrypt, and import their
s390x support patch; per these definitions, 32-bit ARM is assumed to
behave like 32-bit x86, 64-bit ARM, ppc64le, and riscv64 are assumed
to behave like 64-bit x86. This doesn’t fix MIPS builds, but
libmongocrypt builds there are probably incorrect. Closes: #1030701.
Checksums-Sha1:
877246abf4bdc7d6d03e9e0408e3ba74ff795e4c 1992 intelrdfpmath_2.0u2-7.dsc
0f62035dd17384a173fe43d22ad32ec6de788eda 6228 intelrdfpmath_2.0u2-7.debian.tar.xz
f860e4b1169eb0a1884f112f7e1e31eec0757be7 6336 intelrdfpmath_2.0u2-7_source.buildinfo
Checksums-Sha256:
06c9aaf525ea5db99e62ea92236d29bf370be97716e3967fddece1fd51998c2c 1992 intelrdfpmath_2.0u2-7.dsc
58856cf81353ad6e547af2cdec98430ad37b95fe69214fc25ff836ba8cdb7538 6228 intelrdfpmath_2.0u2-7.debian.tar.xz
7651d565ddcf28f336f452138532d6b988ec9c63f22cd671f26d0bcc7a4ded30 6336 intelrdfpmath_2.0u2-7_source.buildinfo
Files:
586ee317a5866fea1ccb23be2b543661 1992 libdevel optional intelrdfpmath_2.0u2-7.dsc
7a483829bc095a12b95be1508b2cc0bd 6228 libdevel optional intelrdfpmath_2.0u2-7.debian.tar.xz
c63fb18e6b8fc998625ab32135cd366b 6336 libdevel optional intelrdfpmath_2.0u2-7_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEnPVX/hPLkMoq7x0ggNMC9Yhtg5wFAmPhUHgACgkQgNMC9Yht
g5w5yQ//bSvkKHVV6FJ2cp7MOE9VMPxcFeR8YKSfIqrKd72Q5h9dqIDvOg65Lv89
Xe22SXFhFebHc58kKos4u5OoORiV4Zd0I1pY4VOOxtzktwX0YJg3lcVfNdXs2a47
weaZ/s+jL8RimveIYNfENS96shzAmArxBu5gcRJLcNKACCdh0qZEV5klQey8VBzr
tp5j8dZ47Hy0MEMMUoAY7bDey03skxDz5Oh/EgmFs8IpAyOU/XclsDoNzHcKxjSd
6U9S4u5tz045VRDelTscJNgsUUh/ofFNbGCHZ6GEdEyfZ6PhrApPN7t4+EZhel6o
RGY/MEdxHk550l2w9JMxFsI4L+NNg9YILE1iEBHVgDwVTME1QBJZ4wWCKEibRPb/
WNy65w3X7urQLrysccjDR8UqNnZzqkO3FEGnPx52Wwr8YpFmhL63jDMfaxNQn3W7
iW7T+ErIXAXpus6zkNsiuDKKvMgk44BOeWSR+5Ve2UCg/OPD1966MSkczkANvV4a
VcrYL4vF3b+Lj2ml0cVEeBsVYfTiBsLV0F8ZrOKVjX/dUUJ3ea6LVu8YOdDOEqM5
mdCZ6Xaql+KMpsnXB0pikxtm0MpqSfJ6muz7niQZSQWxFEqkt1QH1uqi68SgiBjd
NSaCaXN3Z6Ftk7SrZD4vtxbj7fchlrgHvtOGSbOqeUnP+oCSrQM=
=q5Pj
-----END PGP SIGNATURE-----
Hello, Bug #1030726 in intelrdfpmath reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/intelrdfpmath/-/commit/758574be1ed3ce30ec26c6e5136fdb1691d5213a ------------------------------------------------------------------------ Fix MIPS support Closes: #1030726 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1030726
As a further note, even with the update patch that I supplied, there is
still a later failure on 32-bit mipsel:
float128/dpml_ux_cbrt.c: In function 'bid_f128_cbrt':
float128/dpml_ux_cbrt.c:136:27: error: 'lsd' undeclared (first use in this function); did you mean 'msd'?
136 | | (lsd >> D_EXP_WIDTH);
| ^~~
| msd
float128/dpml_ux_cbrt.c:136:27: note: each undeclared identifier is reported only once for each function it appears in
Regards,
This patch is broken. I attempted a build and this is what happened: (sid_mips64el-dchroot)roberto@eller:~/mips64el/intelrdfpmath-2.0u2$ dpkg-buildpackage dpkg-buildpackage: info: source package intelrdfpmath dpkg-buildpackage: info: source version 2.0u2-6 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Stephen Kitt <skitt@debian.org> dpkg-buildpackage: info: host architecture mips64el dpkg-source --before-build . debian/rules clean dh clean debian/rules override_dh_auto_clean make[1]: Entering directory '/home/roberto/mips64el/intelrdfpmath-2.0u2' /usr/bin/make -C LIBRARY clean make[2]: Entering directory '/home/roberto/mips64el/intelrdfpmath-2.0u2/LIBRARY' makefile.iml_head:356: *** Unknown host architecture mips64. Stop. make[2]: Leaving directory '/home/roberto/mips64el/intelrdfpmath-2.0u2/LIBRARY' make[1]: *** [debian/rules:16: override_dh_auto_clean] Error 2 make[1]: Leaving directory '/home/roberto/mips64el/intelrdfpmath-2.0u2' make: *** [debian/rules:13: clean] Error 2 dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2 I have attached an updated patch that seems to resolve this issue and allows the build to execute on mips64el and mipsel. Regards,
And even with the build continuing on mips64el I see this:
float128/dpml_ux_trig.c: In function '__dpml_bid_ux_degree_reduce__':
float128/dpml_ux_trig.c:254:9: warning: implicit declaration of function 'UMULH' [-Wimplicit-f
unction-declaration]
254 | UMULH((UX_FRACTION_DIGIT_TYPE) exponent, RECIP_TWELVE, k);
| ^~~~~
When I build libmongocrypt against the resulting libintelrdfp-math, the
libmongocrypt will then fail at link time:
/usr/bin/ld: /home/roberto/mips64el/intelrdfpmath-2.0u2/debian/libintelrdfpmath-dev/usr/lib/mips64el-linux-gnuabi64/libbidgcc000.a(dpml_ux_ops_64.o): in function `__eval_pos_poly':
(.text+0xe4): undefined reference to `UMULH'
/usr/bin/ld: (.text+0xfc): undefined reference to `UMULH'
/usr/bin/ld: (.text+0x144): undefined reference to `UMULH'
/usr/bin/ld: (.text+0x160): undefined reference to `UMULH'
/usr/bin/ld: (.text+0x168): undefined reference to `UMULH'
/usr/bin/ld: /home/roberto/mips64el/intelrdfpmath-2.0u2/debian/libintelrdfpmath-dev/usr/lib/mips64el-linux-gnuabi64/libbidgcc000.a(dpml_ux_ops_64.o):(.text+0x17c): more undefined references to `UMULH' follow
It might be better to simply declare intelrdfpmath '[!mipsel
!mips64el]'. Sadly, my experience with Intel libraries (I maintained
TBB in Debian for several years) is that they only put effort into the
architectures that are important to them and that you can't assume that
their code will work on other architectures. That could well be the
case here.
Regards,
We believe that the bug you reported is fixed in the latest version of
intelrdfpmath, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1030726@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Stephen Kitt <skitt@debian.org> (supplier of updated intelrdfpmath package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 06 Feb 2023 21:57:38 +0100
Source: intelrdfpmath
Architecture: source
Version: 2.0u2-8~exp1
Distribution: experimental
Urgency: medium
Maintainer: Christian Stalp <chris@chrishell.de>
Changed-By: Stephen Kitt <skitt@debian.org>
Closes: 1030726
Changes:
intelrdfpmath (2.0u2-8~exp1) experimental; urgency=medium
.
* Specify the host architecture when cleaning too.
* Lower the optimisation setting to -O1 and enable the test suite (at
-O2 the test suite loops endlessly).
* Move all the s390x architecture handling to the s390x-specific
patch.
* Fix MIPS support. Closes: #1030726.
Checksums-Sha1:
fff7bf69c2e3449b48ee6473e9379fb2e99fb7dd 2012 intelrdfpmath_2.0u2-8~exp1.dsc
2aeb468a439bc848f4bbfb2c2ce1cc16a40dbe61 7160 intelrdfpmath_2.0u2-8~exp1.debian.tar.xz
05dbb1e30ce894433060ae6287fd1af96456dbe6 6356 intelrdfpmath_2.0u2-8~exp1_source.buildinfo
Checksums-Sha256:
e2e03e892e03e2bb6ba37e7171e10149aab324864b26ea0398d76122f670747a 2012 intelrdfpmath_2.0u2-8~exp1.dsc
6e5480754338309fb1c665cb04dfecc3ce7e509e5e14ce6569ea5c0379d050c2 7160 intelrdfpmath_2.0u2-8~exp1.debian.tar.xz
a574f1f75b20893a8b5cfadaee69c1af102f74d149be6d5ff963ec6d7241f0c3 6356 intelrdfpmath_2.0u2-8~exp1_source.buildinfo
Files:
f458dc9950ecf7733891b6b243f5153f 2012 libdevel optional intelrdfpmath_2.0u2-8~exp1.dsc
2db2dd402edad14fae5a467d74e8eca3 7160 libdevel optional intelrdfpmath_2.0u2-8~exp1.debian.tar.xz
fddd679e979a668584fc58a28f2c78af 6356 libdevel optional intelrdfpmath_2.0u2-8~exp1_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEnPVX/hPLkMoq7x0ggNMC9Yhtg5wFAmPhaekACgkQgNMC9Yht
g5zwGw/+LPjalJIHnAkVAsiXolCvfBnTCtjqHqNDpxhPSUtxrWAISKePKKYp+93C
ytqQJo8On5gIoY2NOxMY8MMRHJMhV8s8jDH2E8l+Jy78UymaRPeUEuGBvBEBax8N
SZRBgEw727eksnyOI+M94lpw7GXDvUkpGCDAcnDWuZf528ujndT5ZWbZFW+pAsn0
SoCUJPeRoFXZS/yXS+aqDVidajG+UjSOOD9uDigMkOiDXInGDMkMXYSahi7atz5J
mQuN4mipJdJ2DHh58PmB+VFYsSfEozPGYI1BEytgcZj0MbBzOsGJTpG6zW9Wlem+
5w/C+fK2nQ5/U0UzXk4dz6pqYuTiDx6B8efVx/DnUI2ocBs8J1rVkI8bLQIt9hwS
28VkSmyS47076e800QUQPXQGLaIRbvf8PkCT787tll3B8ETEKlhvGDqGH3iswUac
0vKExC2i2vekmFqGu1HtlYFjgrnSf7qvPhbV2i1nmxpj/5B2vWVEymo95EXK1XNS
thfGzVicJw84KRla5NRI6vJrGdnJsoGSDyhkY2z73ZPcM2iJnAjDbBiJHddwUKA4
k0CSdNVlJn4VChVeMcn4oETNfQE39GzsENJ5mN4KMWibhq3qNg2RKf/Z7emJifqG
oIjz3KTG3UiuQjkM+g53sj1Og3BWMQB+Hg1g9RfqzTXOLi10vvo=
=VRib
-----END PGP SIGNATURE-----
Yes, it seems like we’d really need a mips_macros.h implementation on MIPS. I enabled the test suite, and the result is basically that the library only works fully on amd64, i386 (nearly, with two test failures out of ~120,000 test cases), and ia64, which matches the architectures which the library claims to support. On other architectures, the number of failures varies, up to 12.5% of test cases on s390x. So really I should change the library to [amd64 i386 ia64]... Do you have a good way of validating whether the library is good enough for libmongocrypt’s purposes on non-Intel architectures? Regards, Stephen
That was my suspicion as well. That's unfortunate. libmonogocrypt has a test suite, which we don't execute as part of the package build because of upstream's robust CI. However, we could definitely enable it and it would be sufficient to let us know that the library is adequate for what libmongocrypt needs. That said, upstream is quite close validating that libmongocrypt works with libdfp, so that might provide a near-term alternative if you decide that the best thing to do from a quality perspective is to restrict the architecture list of intelrdfpmath. Regards,
On Tue, 7 Feb 2023 15:17:05 -0500, Roberto C. Sánchez <roberto@debian.org> wrote: Given how late we are in the Bookworm release process, I’ve updated the package description to mention that the library is only fully functional on x86 architectures and ia64, but may be sufficient on others (for free42, it is, at least on ARM), and haven’t restricted the architectures. That doesn’t help on MIPS of course... Does libdfp work on MIPS? I got the impression it’s mainly supported on IBM platforms (POWER and S/390) but perhaps that’s outdated! Regards, Stephen
After having talked with the developer who has implemented the new DFP-dependent features in libmongocrypt, it seems that portability (beyond amd64, arm64, ppc64el, and s390x) was in view for him. He did look at libdfp and concluded that it has some benefits over Intel DFP, but clearly building on MIPS family architectures is not achievable even with libdfp. As far as it being outdated, I am not certain but I think that upstream might have gone away from tagged/versioned releases and more to a model of "clone master and build from that". In that sense, it wouldn't be outdated, but the version in Debian would be about ~18 months out of date by that measure. In any event, upstream decided that rather than implement support for libdfp they would implement a switch to enable/disable building with Intel DFP (and thus the features that depend on it). That will allow for libmongocrypt to be able to build on all of the release architectures for bookworm. That new upstream release is due out today or tomorrow. The upstream CI gives sufficient coverage with testing that I am confident in all the 64-bit non-MIPS arches and I would be surprised if 32-bit ARM were an issue given the fairly robust upstream tests. In any event, thanks for leaving the architectures as they are for the moment. Regards,