Bug#462249: libaudio-flac-header-perl: FTBFS on armel, hppa, m68k, powerpc, s390, sparc

[Niko Tyni]

On Wed, Jan 23, 2008 at 06:17:15PM +0200, Niko Tyni wrote:
> On Wed, Jan 23, 2008 at 03:07:48PM +0200, Riku Voipio wrote:
> > Package: libaudio-flac-header-perl
> > Version: 1.9-1
> > Severity: serious
> > Justification: no longer builds from source
>  
> > Since the architectures where testsuite fails have little in common,
> > it could be that this bug is a bug in the testsuite rather than
> > testsuite exposing bugs in libaudio-flac-header-perl code.
> 
> No, it seems to be a "real" bug. I could reproduce this on hppa
> (paer.d.o), and the failing test is due to differing cuesheet information:
> hppa gives
> 
> REM FLAC__lead-in 1604068
> REM FLAC__lead-out 170 153200460
> 
> where it's supposed to be
> 
> REM FLAC__lead-in 88200
> REM FLAC__lead-out 170 153200460
 
OK, I'm as far as seeing that this code (in Header.xs:250 or so)

 newSVpvf("REM FLAC__lead-in %"UVuf"\n", cs->lead_in);

where cs->lead_in is a FLAC__uint64 and contains 88200, gives the Perl
string "REM FLAC__lead-in 1604068" on hppa. An explicit cast fixes it:

 newSVpvf("REM FLAC__lead-in %"UVuf"\n", (unsigned int) cs->lead_in);

I can't really say I understand what's happening. The UVuf macro is
defined as "lu" (in /usr/lib/perl/5.8/CORE/config.h), and 

 fprintf(stderr, "%lu\n", cs->lead_in) 

gives 88200 as expected.

This is starting to look like a Perl bug in Perl_newSVpvf()...

Cheers,
-- 
Niko Tyni   ntyni at debian.org