Re: mips64el/mipsel and testing migration
On Sat, Feb 04, 2023 at 05:49:12PM +0200, Adrian Bunk wrote:
> On Sat, Feb 04, 2023 at 09:59:23AM -0500, Roberto C. Sánchez wrote:
> >...
> > If that is the case, then I am puzzled how intelrdfpmath would have
> > migrated to testing without being able to build on mips64el/mipsel
>
> intelrdfpmath having never been built on mips* is not an RC bug or
> testing migration blocker for intelrdfpmath since there are no old
> binaries of intelrdfpmath in unstable.[1]
>
I see.
> > and
> > it makes me think that I might need to be concerned that libmongocrypt
> > might not migrate in time.
>
> libmongocrypt is currently in testing, so the 12th is not a hard
> deadline here.
>
Ah, that's very helpful. I was concerned that there might not be time
to resolve this problem. I am grateful to have a little room here to be
able to get things properly in order.
> > If that is not the case, and the excuses are spurious because the lack
> > of availability on mips64el/mipsel won't prevent testing migration, that
> > would be good to know as well.
> >...
>
> libmongocrypt does have old binaries on mips* in unstable,
> which blocks testing migration of libmongocrypt.
>
> There are 3 options for handling this:
>
> 1. Is there a way to build libmongocrypt without intelrdfpmath?
>
Upstream has mentioned the possibility of being able to build with
libdfp. However, I suspect that no action has yet been taken on this as
the first step was to get everything working with Intel DFP. I will
inquire about this.
> 2. Fixing intelrdfpmath on mips*
>
Seems unlikely. More below.
> 3. "reportbug ftp.debian.org" could be used to request removal of the
> old mipsel/mips64el binaries of libmongocrypt, but that requires first
> making the build dependency in mongo-c-driver exclude architectures
> where libmongocrypt is no longer available.
> If !pkg.mongo-c-driver.no-libmongocrypt is still a usable configuration,
> then [!mipsel !mips64el] could be used there.
>
OK. This is something I'd rather avoid, but in the event we can't come
up with anything else, it might be the only option.
>
> I will look whether 2. is feasible. intelrdfpmath does build on not
> explicitely supported architectures like s390x, and MIPS might be a
> victim of explicit support code that is now half-broken.
>
The mips64el/mipsel builds of intelrdfpmath fail like this:
In file included from float128/dpml_ux.h:39,
from float128/dpml_ux_bid.c:32:
float128/dpml_private.h:215:14: fatal error: mips_macros.h: No such file or directory
215 | # include "mips_macros.h"
| ^~~~~~~~~~~~~~~
compilation terminated.
Inspecting float128/dpml_private.h I see that it refers to a variety of
platform-specific macro headers. Some are present in the source
distribution (e.g., ix86, which also covers hppa, amd64, and sparc),
while several are #include'd but not present in the source (e.g., mips,
cray, vax, and alpha).
This helpful comment is present just prior to the #include's:
/* Environment specific macro definitions that pre-empt the generic
(and perhaps slow) definitions below are in include files per
ARCHITECTURE. The macros defined in these files should be a subset of
the macros defined below (i.e. if there is a specific version, there
should also be a generic version that will work with any ANSI C
compiler). [ In practice, we may not get around to writing the generic
versions until we need them. ] */
It makes me think that, (a) if they haven't made it around to
implementing the missing pieces yet that they never will, and (b) that
it might be possible to simply drop the #include for mips and let the
slow generic macros be used on mips.
In any event, I can file a bug against intelrdfpmath requesting that the
maintainer look into that possibility.
Regards,
-Roberto
--
Roberto C. Sánchez
Reply to: