How to make perl bytecode if sub is there in another file.pl so that I can get all perl script in to binary to give for usage but I am getting codedump warning.
Here is the example how I have done!
File: add.pl
require "util.pl"; $a = 1; $b = 2; $res = add($a,$b); print $res;
File: util.pl
sub add()
{
my ($a,$b) = @_;
my $c = $a + $b;
return $c;
}
1; #to return true
Then when I run:
perlcc add.pl ./a.out
I get
Segmentation fault (core dumped)
I also tried
perlcc add.pl util.pl
but it says
/usr/bin/perlcc: using add.pl as input file, ignoring util.pl
Note:
If both are in single file
perlcc file.pl
and
./a.out
will work
Advertisement
Answer
I cannot answer for the actual compiler problem, but let me make a few notes.
<Edit> the more I look at this, the more I think that the problem is the namespacing of the add function. When they are in the same file, the function is declared in the main namespace. I think that would be true of the require-d file too, since there was not package declaration. Either way, these are still some good notes that I hope help. </Edit>
- You really should use
strictandwarningspragmas - You shouldn’t use
$aand$b, because they are semi-magical in Perl and should be avoided (yeah, thats a weird one) - Perl prototypes are not the same as most languages, and even then the empty prototype
()on youraddfunction is incorrect, best to leave it off
Those things said here is how I would format my files.
File: add.pl
use strict; use warnings; use MyUtils; my $x = 1; my $y = 2; my $res = add($a,$b); print $res;
File: MyUtils.pm
package MyUtils;
use strict;
use warnings
use parent 'Exporter';
our @EXPORT = ('add');
sub add
{
my ($x,$y) = @_;
my $c = $x + $y;
return $c;
}
1;
This uses the more modern module/package formalism for reusable libraries. The use directive contains a require directive, but does it at compile-time rather than run-time.
The Exporter module (and the @EXPORT variable) correctly import the function into the script’s namespace (typically main).
Perhaps perlcc will like these changes better; but even if not, these are good practices to get used to.