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

[sisyphus1 at optusnet.com.au]

-----Original Message----- 
From: Daniel Kahn Gillmor
Sent: Thursday, May 02, 2013 9:56 AM

> On 04/28/2013 01:34 PM, Thorsten Glaser wrote:
> > fail
> >
> > t/printf.t fails the first subtest in 's' (only):
> > 1s: 0 (instead of 80)
>
> hm, it looks like it's failing on several platforms, including a bunch
> of big-endian ones:
>
>  https://buildd.debian.org/status/package.php?p=libmath-mpfr-perl
>
> I'm looping upstream into this discussion -- rob, have you run these
> test suites on big-endian architecture machinery?

No, I don't think so.
I've never really thought much about endianness - as it's generally taken 
care of.

>  do you think the test
> suite should complete successfully on those platforms?

My first thought was that it shouldn't matter ... but if sizeof(IV) and 
sizeof(mp_prec_t) are also different, then one starts to wonder about what 
might happen.
(The P type specifier is intended to take an mp_prec_t, but in Math::MPFR 
it's handed an IV.)

I have some builds of Math::MPFR where the IV is 8 bytes and the mp_prec_t 
is 4 bytes, and that's not a problem for me. But it's a little-endian 
architecture.

It might be enlightening (for me, at least) to see what the following C 
script outputs on these troublesome machines:

/*********************************/
#include <stdio.h>
#include <mpfr.h>

int main(void) {

mpfr_t x;
/* IV p = 80; */

mpfr_set_default_prec(80);
mpfr_init_set_si(x, 100, MPFR_RNDN);

printf("size of mp_prec_t: %d\n", sizeof(mp_prec_t));
mpfr_printf("precision of x: %Pu\n", mpfr_get_prec(x));
/* mpfr_printf("precision of x: %Pu\n", p); */

mpfr_clear(x);

return 0;
}


/*********************************/

As it stands, that script will give us the size of the mp_prec_t and will 
also verify that the mpfr library is, in fact, handling the P type specifier 
correctly.

You could also replace the "IV" in that script with whatever is reported by 
'perl-V:ivtype', then comment in the 2 lines of code that are presently 
commented out. That way we additionally get to see how that architecture 
handles the case where the P specifier is given an IV.

If we find that the problem is as you've suspected, then I'll probably just 
skip that test on big-endian machines where ivsize != mp_prec_t size. (I'm 
assuming that there's no problem when ivsize == mp_prec_t size.)
How would a perl script best determine whether the machine is big-endian or 
not ?

(The wrapping of mpfrf_printf, etc. is very rudimentary - I don't regard it 
as all that useful in a perl context.)

Cheers,
Rob