On Sun, 28 Dec 2025 20:15:45 +0200 Niko Tyni <[email protected]> wrote:
Control: tag -1 patch
On Fri, Nov 21, 2025 at 10:02:39PM +0100, Paul Gevers wrote:
> Source: libobject-pad-perl
> Version: 0.821-1
> Severity: serious
> Justification: ftbfs
> User: [email protected]
> Usertags: i386
> Control: -1 blocks 1118269
> The last upload of libobject-pad-perl failed to build on the buildds on
> i386.
> # Failed test 'class scope with import version 0.821 does not imply use
> strict'
> # at t/51pragmata.t line 27.
> # Code failed to compile - Global symbol "$def" requires explicit package
> name (did you forget to declare "my $def"?) at (eval 21) line 3.
> # Global symbol "$def" requires explicit package name (did you forget to
> declare "my $def"?) at (eval 21) line 3.
Hi, this seems to be a floating point precision thing specific to i386.
The following C test program shows it:
#include <stdlib.h>
#include <stdio.h>
int main(void) {
double d = strtod("0.821", NULL);
printf("int(%.25f * 1000) ==\nint( %.28f) ==\n %d\n", d, 1000 *
d, (int)(1000 * d));
}
On amd64, the result is 821 as expected by the libobject-pad-perl code:
int(0.8209999999999999520383653 * 1000) ==
int( 821.0000000000000000000000000000) ==
821
but in an i386 chroot on an amd64 host we get 820:
int(0.8209999999999999520383653 * 1000) ==
int( 821.0000000000000000000000000000) ==
820
Not sure what to make of this, but the attached patch that applies
round(3) before casting to integer fixes it for me. Hopefully #including
<math.h> is acceptable upstream, but if not I'm sure they can come up
with something better.
I found this [1] which seems related.
An upload would be appreciated as this is blocking the ongoing ocaml transition.
Cheers,
Emilio
[1]
https://www.xatlantis.ch/index.php/blog/linux-programming/24-double-precision-error
