Bug#1121148: libobject-pad-perl: ftbfs on i386

[Niko Tyni]

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: debian-qa at lists.debian.org
> 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.

Happy holidays,
-- 
Niko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-floating-point-handling-in-version-comparison.patch
Type: text/x-diff
Size: 1081 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/attachments/20251228/9f4e50f3/attachment.patch>