Autrijus, I think the ability to include libperl.so in a PAR executable is fine, and I do not particularly think it matters whether it is the default or not, so long as options for both choices exist. However, I'd like to point out that it is NOT always a good idea even if you want a "truly stand-alone executable." This point will also lead to a feature request.
On MacOS X, perl is included in the OS distribution. However, the libperl shipped with MacOS 10.2 is not backwards compatible with MacOS 10.1 because libSystem (basically the libc equivalent) changed, and libperl imports different symbols on the two platforms. Similarly, many of the shared libs in the standard Perl library (/System/Library/Perl on MacOS X) from 10.2 do not work on 10.1. I do not know whether 10.1 libraries would work on a 10.2 system, as I do not have a 10.1 system for testing. More generally speaking, one should not expect shared libraries from one version of an operating system to work on another version of the operating system. The only way to have a "truly stand-alone executable" is to bundle *all* of the app's libraries (either as local copies of shared libs or statically linked) with the app, but that is not really practical (or often legal), and brings its own list of disadvantages, too. Thus, on a system like MacOS X where perl is part of the OS distribution, I think the correct solution is not to bunlde libperl *and* not to bundle ANY modules that the OS provides. Of course, this has its own risks, but if the user has messed up their OS's perl install, that's their own fault (just like if they mess up libc, lots of things will fail). While you've promised a "no libperl" option for PAR 0.70, I do not think there is a "local modules only, no system modules" option (if there is, I missed it). This could be implemented as a --exclude-dir option to omit any modules below the specific root (e.g. on MacOS X, "--exclude-dir /System"), or many other ways. Thanks, Barry
