B-C
view release on metacpan or search on metacpan
Copyright (c) 1996-1997 Malcolm Beattie
Copyright (c) 2008-2011, 2017-2019 Reini Urban
Copyright (c) 2012-2017 cPanel Inc
Releases: http://search.cpan.org/dist/B-C/
Code+Issues: http://github.com/rurban/perl-compiler/
(was until 2016 at http://code.google.com/p/perl-compiler/)
OVERVIEW
Malcom Beattie's perl compiler ("perlcc") updated to 5.10 - 5.24 and cperl,
with most bugs fixed (also for 5.6. and 5.8) and new features
added. It compiles to C or platform-compatible Bytecode.
Development is in the master branch at https://github.com/rurban/perl-compiler,
the stable branch is called 'release', the newest perl releases usually don't work
immediately. I typically need 6 months to catch up for perl5. With cperl B-C is
included in CORE, so this is supported to work there.
Known issues:
See https://github.com/rurban/perl-compiler/issues/
* run-time attributes (e.g. use open attributes, Attribute::Handlers, ...),
but ok at compile-time.
* some compile-time side-effects can not be reproduced when running a compiled
binary, such as BEGIN { chdir $dir }, i.e. most system and IO calls. use
INIT {} instead.
* p5p Carp >= 1.42 is broken. 5.26++, rather use cperl.
* Certain XS module using compile-time pointers need special workarounds:
* DBI patched by the compiler (#359)
* Encode > 2.58 (#71, #305, RT 94221), patched by the compiler
* Net::DNS > 0.67 (#305, RT 94069)
* IO::Socket::SSL > 1.995 (#317, RT 95452)
* DBD::mysql > 4.027 (RT 97625)
* Todo: FCGI, Coro, Moose with meta->make_immutable
* Class::XSAccessor see t/testc.sh 400 for 2 of 3 possibilities how to use it
Mailinglist:
http://groups.google.com/group/perl-compiler perl-compiler@googlegroups.com
INSTALL
cpan B::C
On strawberry I needed
perl Makefile.PL FIXIN="perl -S pl2bat.bat"
On Windows and AIX for 5.12 and 5.14 you need to patch and rebuild CORE perl:
ramblings/Export-store_cop_label-for-the-perl-compiler.patch
For 5.14 and 5.15 I recommend also the following patches:
ramblings/revert-B-load-BEGIN.patch (The 5.14.1 version)
ramblings/Carp-wo-B.patch
We generally discourage the use of perl since 5.16 unhandled and
unacknowledged security problems with the implementation of "unicode"
symbols and packagenames, where they really implemented binary names
for all symbols without any checks and further support of such binary
names. Identifiers are not identifiable anymore.
See the warning at perl Makefile.PL.
5.20 improved support for binary names for most syscalls, dumpers and
APIs, but TR39 and strict names are still not handled, the problems
are not understood and reactions are generally hostile.
5.18 made it 20% bigger with the implementation of COW strings.
Most strings cannot be stored statically anymore since then.
The best perl versions for the compiler are 5.14.4, 5.22.1 and cperl,
since these are the most tested versions, where the coretest suite passes.
USAGE
The Bytecode, C and CC backends are now all functional
enough to compile almost the whole of the main perl test
suite and 99-100% of the top100 modules.
Bytecode was broken upstream with 5.22
CC added a lot of new failures with 5.24
cperl is far superior over perl5, esp. with its advanced compiler
support and less breakage.
In the case of the CC backend, any failures are all
due to differences and/or known bugs documented below.
See the file TESTS.
(1) To compile perl program foo.pl with the C backend, do
perl -MO=C,-ofoo.c foo.pl
Then use the cc_harness perl program to compile the
resulting C source:
perl cc_harness -O2 -o foo foo.c
If you are using a non-ANSI pre-Standard C compiler that
can't handle pre-declaring static arrays, then add
-DBROKEN_STATIC_REDECL to the options you use:
perl cc_harness -O2 -o foo -DBROKEN_STATIC_REDECL foo.c
If you are using a non-ANSI pre-Standard C compiler that
can't handle static initialisation of structures with union
members then add -DBROKEN_UNION_INIT to the options you
use. If you want command line arguments passed to your
executable to be interpreted by perl (e.g. -Dx) then compile
foo.c with -DALLOW_PERL_OPTIONS. Otherwise, all command line
arguments passed to foo will appear directly in @ARGV. The
resulting executable foo is the compiled version of
foo.pl. See the file NOTES for extra options you can pass to
-MO=C.
There are some constraints on the contents on foo.pl if you
want to be able to compile it successfully. Some problems
can be fixed fairly easily by altering foo.pl; some problems
with the compiler are known to be straightforward to solve
and I'll do so soon. The file Todo lists a number of known
problems. See the XSUB section lower down for information
about compiling programs which use XSUBs.
( run in 1.199 second using v1.01-cache-2.11-cpan-39bf76dae61 )