Description of problem: When compile perl script into C code, modules complained Can't locate object method "IVX" via package "B::NV" Version-Release number of selected component (if applicable): $ rpm -qf /usr/lib/perl5/5.8.8/i386-linux-thread-multi/B/C.pm perl-5.8.8-5 How reproducible: always. Steps to Reproduce: 1. create a file tw.pl with this content: #!/usr/bin/perl -w use strict; package mx; sub new {} #sub x { my $m = 5.1; } 1; 2. compile with this line time perl -MO=C tw.pl > t.c Actual results: Got error msg Can't locate object method "IVX" via package "B::NV" at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/B/C.pm line 650. CHECK failed--call queue aborted. Expected results: Compiling ok, produce a compilable .c file: Additional info:
I made a typo on the example; there should be no "#" in front of "sub x".
This is a simpler example to illustrate the same issue. #!/usr/bin/perl $v = 2.35;
Yes, looking at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/B/C.pm, B::NV::save appears to be mostly copied from B::IV::save, and on line 650, the $sv->IVX should be a $sv->NVX - with that change, your examples compile correctly. Indeed, without that change, perlcc doesn't seem to be able to handle floating point values at all. You can fix this locally by applying this patch: --- --- ./lib/B/C.pm 2006-01-13 09:47:39.000000000 -0500 +++ /usr/lib/perl5/5.8.8/i386-linux-thread-multi/B/C.pm 2006-07-21 20:25:39.000000000 -0400 @@ -650 +650 @@ - $xpvnvsect->add(sprintf("0, 0, 0, %d, %s", $sv->IVX, $val)); + $xpvnvsect->add(sprintf("0, 0, 0, %d, %s", $sv->NVX, $val)); --- or by changing byte 18708 of C.pm from 'I' to 'N'. That said, as stated in todays perl5-porters mail on this subject: > Re: [perl #39903] perl C compiler Can't locate object method "IVX" via package "B::NV" > From: "Joshua ben Jore" <twists> > To: perl5-porters > CC: bugs-bitbucket.com > Date: 2006-07-21 17:53 > > B::C, B::CC, and perlcc are not being maintained. I can only > guess as to why you tried to use this. Perhaps to get a single binary, > perhaps to get faster execution or startup, perhaps to hide your source > code. The first two goals can be achieved through tools like PAR and pperl. > > Josh Yes, nothing in perlcc / B::C seems to have been maintained since 1998, so it is unlikely the above will be the only issue you encounter when trying to use perlcc for any real app. I suggest you seriously examine why you need to use these tools; but I'll apply the above patch on the next release.
assigning to rnorwood
This is slated to be resolved in a newer version: http://code.google.com/p/perl-compiler/updates/list
Nick, Thanks for update!