perlcc is still disclaimed as being experimental.

Effective the next release of Perl 5,

perlcc, the byteloader and the supporting modules (B::C, B::CC, B::Bytecode, etc.) are no longer distributed with the perl sources. Those experimental tools have never worked reliably, and, due to the lack of volunteers to keep them in line with the perl interpreter developments, it was decided to remove them instead of shipping a broken version of those.

I heard perlcc stuff was actually slower than compiling Perl sources anyway, so there's no benefit packagers don't already provide.

Curious to know if there are plans in Perl 6 to ease generation of stand-alone executables?

particle and I put together a proof of concept to turn Parrot PBC files into standalone executables linked against a shared libparrot. It only needs a little bit of polish to work. (It does need a working C compiler on the system for now, but there's no reason that requirement always has to be there, if you know more about code generation than I do.)

Speaking of perl5, your link nifty trick is interesting also, and it is quite doable nowadays, but with minor tweaks to perl source tree.

I have my home-grown perl5 executable system, which do on-the-fly unpacks (w/o temporaries, unlike PAR approach), and it is half-way done to a single-file executable.

@INC supports code refs to specialized handlers, so no need to tweak the Perl source.

there is a need to tweak the Perl source, if you really want perl executable with any extension to be linked statically into the main executable.

I was able to statically link into perl58.dll Tcl::Tk and some required for me modules. But you need some kind of linking set and some developed approach if you're going to gather some (unknown) extensions into the main exe.

PS.(keep in mind, this is not PAR approach, where huge ZIP is unpacked into %TEMP%)