Update: You will need to get your program + Perl working on a Windows machine. You run pp on that Windows machine. To my knowledge, you cannot make a cross platform executable with this technology (ie, make Windows exe on a Linux machine), but I could be wrong about that. You will wind up with a normal Windows .exe file. You can do things like stuff an icon in that .exe just like any other Windows program. The .exe version will start a bit slower than the normal version, but other than that, it should be the same.

I suggest that you make a simple "hello world!" program to start with just to familiarize yourself with the mechanics of how to do this. There can be issues like how to include support files or add extra dll into that target .exe. But get started and "on first base" as the first step.

Actually, this question (2) doesn't concern Windows : I'm trying to package with 'pp -P' on macOS and run it on a Linux server. After reading carefully the doc, and adding the '-B' switch (bundle core switches), there's some improvement :

 
Attempt to reload DynaLoader.pm aborted.
Compilation failed in require at <embedded>/XSLoader.pm line 118.
[download]

When you said: an executable for windows without Perl available that got me onto Windows.

Get the basics working first. Then optimize when needed. As I mentioned, I don't think cross platform (Mac to Linux) is going to work. But I have no direct experience attempting that. Create a standalone executable on your Mac. Run that on your Mac. Get that working. Don't mess with -P until after you get the standalone version working (if ever).

I take it that you have your own installation of Perl that you are using instead of the system version. That's fine, but I'm not sure how you went about doing that (question (1) related). This may be contributing to issues related to making a "partial executable".

All your dependencies are pure perl? https://metacpan.org/dist/PAR/view/lib/PAR/Tutorial.pod#Cross-platform-Packages.

Re-reading this I think I see what you are trying to do now (although not the full context). We probably need to see some code to show how you are setting things up.

For #1, there is no standard shebang. It is maybe clearer to call the script using the perl script.pl idiom as then you can be more sure of which perl is used. It's what I tend to do, but others will have different views.

For #2, PAR::Heavy is part of the PAR distribution. You should not need it in your script unless you are trying to use PAR archives packed using PAR::Packer. And even then it is simpler to just pack the whole script into a stand-alone exe and have the user call that. This is also one of the points raised by Marshall in 11137280.

What to do depends on details we have not been given but I'll list some possible options.

If you are distributing scripts for users to call then use pp on each system to pack self-contained executables. Then you don't need to worry about what version of perl is on each system, which version is in use at the time, or what non-core libraries are installed. If you have many scripts then it's easy enough to write a build script to pack a series of such files.

(This is more complex, probably more so than is necessary). If you are using a single master script to call others then you can pack each script as an executable or a PAR file, pack these with the master script (see the --addfile option for pp), and then have logic in your script that calls PAR files when it is run under PAR by testing for $ENV{PAR_0}. It can also conditionally require any PAR libraries in that case so non-PAR systems do not need them (e.g. something like use if $ENV{PAR_0} PAR). If $ENV{PAR_0} is false then call any scripts directly. An issue with this approach is that it requires duplication of any calling logic as there are now two ways of calling each file.

And just to note, files packed using pp --addfile ... can be found under $ENV{PAR_TEMP}/inc.

I've not given a lot of context, it's true : I'm trying to package a collection of Perl 5.8 scripts (actually the PerlPowerTools) as a single file, runnable anywhere and installable without knowledge of the Perl ecosystem (or with limited access rights).

For Windows, the obvious solution is to build an executable (no issue encountered so far). For other systems (most of them come with Perl installed), I see two inconvenients in building an executable as you suggest : 1) small source scripts (1MB) turn into a big executable (10MB) and 2) a different executable would be needed for every possible CPU, right? Please correct me if wrong, that's not my area of expertise. I agree with you that an executable solves many issues, but in this case they are non-existent, because the scripts are pure old Perl 5.8.

But maybe PAR::PAcker is not the right tool for that : what I did not understand is that an external PAR (not packed!) is needed to run a script packed with 'pp -P', and more confusion came because PAR seems to be shipped by default with macOS Perl and Strawberry Perl (even if not a core module). I thought the (uncompressed) Perl code present at the beginning of the packed file would be enough to extract the rest (Zip) transparently (again, please correct me if wrong).

Thanks!

Is 10MB really that big these days? If that is the total size then I don't see the problem since none of your target environments seem to be resource limited. If it is 10MB per exe then size is something to be concerned about given the number of utilities (and a quick check indicates that's the case).

You also aren't restricted to 5.8. PerlPowerTools has passes for many recent perl versions across a range of OSes on CPAN Testers. http://matrix.cpantesters.org/?dist=PerlPowerTools+1.027

I guess a more general question is whether you need to use the perl variants of these tools given that they are likely to be available on the unix variants, and there are ways of getting them for windows through systems such as cygwin and msys2? Strawberry perl comes with at least some of these utilities under its c/bin dir, so you could distribute those as a start. If you can determine where they are sourced from then you can probably get more from there.

WRT your second point, try adding the --unicode switch to your pp call.

See https://metacpan.org/pod/pp#-u,-unicode for more details.