Now I understand I missed to tell you this fundamental detail before,
sorry.
> perlcc seems to be dropping BEGIN blocks entirely, that's the problem.
No, that's correct. Explanation: if I have a module Foo
----
package Foo;
$x = 1;
print "AAA";
sub a { $x }
1;
----
and a main program foo.pl
----
BEGIN { # think use Foo;, expanded for clarity
require Foo;
}
print Foo::a();
----
perl -MO=C foo.pl
calls B::C::compile _after_ it ran the BEGIN blocks; this means that the optree in
Foo that initializes $x, and does "print AAA" has already been freed. So, even if
B::C could save BEGIN blocks, this
is not a good idea, for quite a lot of reasons.
> # foo.plx
> BEGIN {
> print "foo\n";
> }
> print "bar\n";
>
> $ bleadperl foo.plx
> foo
> bar
> $ perlcc foo.plx
> $ ./a.out
> bar
>
> The result from the compiled program should be the same as the
> original. For some reason the BEGIN block is getting dropped when the
> program is compiled. That's a bug.
It is not a bug that the BEGIN blocks are dropped. It is a B::C bug
induced by the perl design that it can't deal gracefully with code in
BEGIN blocks that print()s, or does other things to the "environment"
( OS, screen, disks, %ENV ), or that initializes data structures outside the scope of
perl ( this includes interpreter-local data using MY_CXT ( Opcode.pm ), or creating a
SV holding a pointer to an external data structure, or dup()s filehandles (
Test::Builder ) [1] ). The only solution to these problems is something like
B::Script ( mentioned in april-june on p5p ).
Regards
Mattia
[1] try searching perlcc.PL for Test::Builder...
