Log for attempted build of libmath-mpfr-perl_3.17-1 on m68k (dist=unstable)

[sisyphus1 at optusnet.com.au]

-----Original Message----- 
From: Thorsten Glaser
Sent: Thursday, May 02, 2013 10:57 PM

>
> > It might be enlightening (for me, at least) to see what the following C 
> > script
> > outputs on these troublesome machines:
>
> size of mp_prec_t: 4
> precision of x: 80
> precision of x: 0
>

Thanks for doing that.

So ... on these machines where the test fails,  instead of doing

Rmpfr_sprintf ($buf, "%Pu\n", Rmpfr_get_prec($mpfr1));

we could do:

Rmpfr_sprintf ($buf, "%Pu\n", _repack(Rmpfr_get_prec($mpfr1)));

where sub _repack() looks like:

sub _repack {
  return unpack("V", pack("N", $_[0]));
}

And if we do that, then the test passes ? .... right ?

I'm actually thinking of documenting that _repack($iv) be called if passing 
an IV ($iv) to the 'P' type specifier. The _repack sub would work out what 
(if anything) it needs to do, then return the value that the 'P' type 
specifier can correctly evaluate.
That's not ideal, but at least it means that everyone can use the 'P' type 
specifier if they so desire.
I'll probably further document that _repack() really needs to be called only 
on big-endian machines, and even then only if mp_prec_t and IV are of 
different sizes.

This would necessitate that I write a function that returns the size of the 
mp_prec_t to perl. (Which is not a problem.)

Does this sound feasible, or am I opening a can of worms ?

Cheers,
Rob