Re^2: PAR::Packer shebang + PAR::Heavy missing

[kaldor]

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.

[Marshall]

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".

[kaldor]

After (much) more experiments, I've noticed that the result of 'pp -P' works fine between macOS and Windows (I can pack on a platform an run it on the other without problem, both ways).

On the Linux box where it fails to run, PAR::Heavy is not installed, so the error message is actually clear!
On my mac, PAR::Heavy is installed in both perlbrew (probably done by me) and system perl (not done by me, I think).
On Windows (Strawberry Perl), PAR::Heavy is installed by default (in perl\vendor\lib)


So, this module is not a core module, but apparently "most/many" Perl distributions install it, is it correct?
Should it also be present on the Linux server? I suspect it's not available because its dependency Archive::Zip fails to install.

Many thanks all of you for the advice so far.

[Marshall]

Thanks for the update with your testing results!

I have no idea of how many (percentage wise) of Perl distributions include PAR::Heavy. A Perl distribution will contain all of the CORE Core modules for that release (BTW: to my knowledge this list of CORE Core modules can and does vary between releases). A release may contain other modules past the CORE Core requirements.

From what you describe, I presume that your code (main + modules) is completely pure Perl source code (no XS modules). Binaries are not compatible between Unix based systems (e.g. modern MacOS) and Windows.

I distribute applications in 2 different ways.

(1) For Windows end users: They get a single .exe file. That file contains everything that the user needs independent of whether they have Perl installed or not. Since this file contains the executable of Perl itself, it has to be built upon a Windows system. There cannot be any Perl version or library conflicts because everything is contained within this single .exe file. Typically these programs have a fancy GUI and I don't assume that the end user has read any of the documentation.

(2) For sys admin level folks: I give them the source code. There might be half a dozen utilities and my modules which are used by those utilities. I haven't had the need yet to make an installable Perl package. The number of people involved is so small that I can talk to each user individually to get their installation "up and running". There is a bunch of documentation that comes with an application like this and I expect the user to read and understand the main documents before they try to do anything at all. This is completely different than "click on it" and "follow the program GUI" that an end-user on Windows gets.

I guess you are trying to "split the baby" and be somewhere in-between these scenarios?

In general, a windows user will not have Perl. Nor will they have any knowledge of the "command line". I haven't installed Strawberry Perl myself because I am a long time Active State user. Active State has ended support for their Perl Package Manager tool (ppm). This was nice GUI tool to add packages very quickly because they were pre-tested and it was guaranteed that all dependencies would be satisfied. In the place of ppm, you can create a custom Perl installation file that will include any extra modules that you wish (which actually compile and complete tests according to Active State rules). This can be an .exe or .msi file. You are allowed to re-distribute this file. You have to create a free account on the Active State site to do this, but I've done it. BTW, if you make a Perl installation like this, I strongly recommend adding cpan and cpanm to the build!

A "partial executable, source code only" will work well if you are distributing code within your organization or close affiliates where you know what versions of Perl are being run. Be aware that the "system Perl" can be quite out of date versus the current release.

[swl]

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

[kaldor]

Yes, currently only printing a string.
Thank you for the tutorial link, I had not seen it.