PAR::Packer::VERSION

Hi, For a binary that is created with pp, is it possible to know (show) the version of the packer? $PAR::VERSION is available, but $PAR::Packer::VERSION is not. That's understandable. However, I think it would be helpful in case of problems to know what version of the Packer produced the binary.

Re: Including shared libraries

On Thu, 30 Jun 2016 00:14:00 +0200 Roderich Schupp <roderich.sch...@gmail.com> wrote: > On Wed, Jun 29, 2016 at 11:49 PM, Johan Vromans <jvrom...@squirrel.nl> > wrote: > > > pp executables are not as stand-alone as the ones from Cava and > > PerlApp. > > &g

Shared double?

Hi, When shared libraries are packed it seems they are unpacked twice: /tmp/par-6a76/cache-XXX: -rw-r--r-- 1 jv jv 43912 Jun 30 18:56 05726ab0.pm -rwxr-xr-x 1 jv jv 17054 Jun 30 18:56 0e41dd30.so ... -rw-r--r-- 1 jv jv8317 Jun 30 18:56 fe92a6f3.pm drwxr-xr-x 6 jv jv

Re: PAR::Packer::VERSION

On Thu, 30 Jun 2016 18:48:43 +0200 Roderich Schupp wrote: > What about a static string in the executable that > you could grep for, e.g. "packed by PAR::Packer VERSION". Good suggestion. Reminds me of the old days of SCCS, where "@(#)" was a magic string that you

Re: Shared double?

On Thu, 30 Jun 2016 22:28:26 +0200 Roderich Schupp wrote: > Yes. I know it's stupid, but the PAR::Packer code is a mess (mind you, I > didn't write it, I just keep it alive) Hmm. This smells like PAR is factually a discontinued product. The official PAR website

Re: Including shared libraries

On Wed, 29 Jun 2016 22:18:12 +0200 Roderich Schupp wrote: > Use pp --link=... But your have to figure out the list of additional > libraries by yourself. Yes, I can do that... I'm afraid we have different interpretations of 'stand-alone'. pp executables are not as

Including shared libraries

Hi, pp automatically includes libperl.so and the .so's for the XS modules. Can it be made to include all necessary system libraries as well? For example, when I package a wxPerl program, the resultant executable requires compatible wxWidgets libraries to be present on the target system. I would

Re: Including shared libraries

On Sat, 2 Jul 2016 09:30:30 +0200 Ch Lamprecht wrote: > With pp they don't even have to install, they click and it just runs > fine. I'm using pp now for 10 years to deliver an executable that > includes Postgres client libraries and Tk UI. It works fine on Linux > MacOS and

Re: Shared double?

On Mon, 4 Jul 2016 10:25:39 +0200 Roderich Schupp wrote: > PAR::Packer also uses a set of rules for those > Perl modules where static analysis - for some reason or other - is > known to produce incomplete dependency information. They're actually > in Module::ScanDeps,

Re: Including shared libraries

On Mon, 4 Jul 2016 10:51:17 +0200 Roderich Schupp wrote: > > For example, the functions > > abstract out whether the application is running bare (unpackaged, e.g. > > during testing and development) or packaged. > > You could e.g. test for $ENV{PAR_TEMP} to exist.

Looking for packagers

Hi, I want to make life easy for users of some of my Perl tools by providing binary kits. This eliminates the need for them to go through the sometimes tedious process of building a package which, as we all know, may involve installing build tools, dependent packages, and so on. I'm looking for

Updating PAR executables

Hi, I have a perl application that consists of pure perl modules only. When I build a stand-alone executable for this application, is it possible to update one or more of my modules without rebuilding it? Background is that I have limited access to some platforms (Windows, Mac) so I would like

Re: Updating PAR executables

On Thu, 23 Mar 2017 20:48:41 +0100, Roderich Schupp wrote: > I have one issue if I read this correctly: you're reusing the SHA1 > checksum from the "old" exe. Yes. I've already fixed that :) . -- Johan repar.pl Description: Perl program

Re: Updating PAR executables

On Wed, 22 Mar 2017 23:29:57 +0100, Johan Vromans <jvrom...@squirrel.nl> wrote: > This is a procedure that does seem to work: Attached is a proof-of-concept program that supports this procedure. It is two-step: repar --split=orig.zip orig.exe Splits the zip section out of the

Re: Updating PAR executables

On Wed, 15 Mar 2017 00:35:36 +0100, Roderich Schupp wrote: > If that's the case, the following might work (haven't actually tried > this). Finally got to trying this. >1. Get any packed executable (e.g. pp a hello-world one liner) from > your target platform. >

Updating PAR executables

Hi, I have a perl application that consists of pure perl modules only. When I build a stand-alone executable for this application, is it possible to update one or more of my modules without rebuilding it? Background is that I have limited access to some platforms (Windows, Mac) so I would like

Re: [EXTERNAL] Re: par-packer-1.037 installation issues

On Tue, 1 Aug 2017 17:42:32 -0400, "Hou, Ying" wrote: > I installed dmake and MinGW. Then I ran perl makefile.pl with no errors > > When I typed dmake > It says error code 129 while making main.o > And error code 258 while making subdirs > A window promps out > cc1.exe the

Using INNO installer to install packaged binaries

Hi, When creating a standalone (GUI) binary, I use the attached innosetup.iss to create a Windows installer for it. Part of the install process is a dummy run of the application, to pre-fill the cache folder. For this, I add a line at the beginning of the program: exit if @ARGV == 1 &&

Re: Par::packer installation issues

On Mon, 7 Aug 2017 14:18:40 -0400, "Hou, Ying" wrote: > Any input was very much appreciated. Remove aything ActiveState related, also MinGW. Install CitrusPerl from https://sourceforge.net/projects/citrusperl/ according to the instructions. Open a CitrusTerm window and type:

Pod::Usage and PAR packaged binaries

Hi, I usually use Pod::Usage to display --help and --manual texts from POD. use Pod::Usage; use Pod::Find qw(pod_where); pod2usage( -input => pod_where({-inc => 1}, __PACKAGE__) ); This doesn't work if the program is PAR packaged. Has anyone already figured out how this can be made to

Re: Pod::Usage and PAR packaged binaries

On Wed, 8 Nov 2017 18:43:52 +0100, Roderich Schupp wrote: > A clumsy way would be to explicitly add the .pod with --addfile, then > locate it relative to the toplevel cache directory, $ENV{PAR_TEMP}. Yes, that is the approach I use now. Clumsy, but it works... --

Re: Multiple entry points (MS Windows)

Hi Oliver, On Sat, 25 Apr 2020 12:08:31 +0200, Oliver Betz wrote: > An easy approach is to continue using pp to build the required > environment. Extract it immediately afterwards. Look at my ugly hack > "unpar.cmd" to see one way to do it. I've uploaded a perl GUI program:

Search path for libraries

The packer has a --lib parameter to set the module search path. Is there something similar for shared libraries?

Filtering

By default PAR::Filter::PodStrip is applied to all modules. This can be disables globally with PAR_VERBATIM=1 . Is it possible to disable this filter with --modfilter ? -- Johan

Multiple entry points (MS Windows)

Hi, I have an application that comes in two forms: as a command line tool, and as a GUI tool. I want to package these in a single binary, using pp multi-script feature. So far, so good. But on Windows it matters whether the program is built with --gui or not. If I build with --gui invoking the

Re: Multiple entry points (MS Windows)

Hi Oliver, On Fri, 24 Apr 2020 17:16:37 +0200, Oliver Betz wrote: > which benefit do you expect from packing: > > Avoiding "installation", reducing size, or something else? Mostly avoiding complexity and unnecessary overhead. The cli version is fully contained in the gui version. Reducing

Re: Multiple entry points (MS Windows)

Hi Oliver, Thanks for all suggestions. A bit of background: I am 100% linux user/developer. Since Windows people want to run some of my applications and since most Windows users are not capable of installing perl and modules and so on I figured out how to use PAR (pp) and InnoSetup to produce

Re: Multiple entry points (MS Windows)

On Fri, 24 Apr 2020 19:40:58 +0200, Oliver Betz wrote: > Which kind of complexity and overhead do you mean? Having multiple copies of the same code installed may sooner or later cause confusion. > What would be the drawback of using a (subset of a) portable Perl > distribution together with

Re: Multiple entry points (MS Windows)

On Fri, 24 Apr 2020 20:21:22 +0200, Kenneth Ölwing wrote: > What do you mean by 'lack of symlinks'? I must admit I haven't really kept up with Windows lately (and I don't plan to). Anyway, the symbolic links are of no real importance to this discussion.

Re: Multiple entry points (MS Windows)

On Sun, 26 Apr 2020 17:57:23 +0200, Oliver Betz wrote: > it was not so difficult as I thought initially so I compiled a 64 bit > wrapper including the icon: Great! I unpacked the zip and tried to run. First problem: the .exe files are not executable: H:\cp> wxchordpro_console.exe Access

Re: Multiple entry points (MS Windows)

> Welle > > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> > Virenfrei. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> > <#DAB4FAD8-2DD7-40BB

Re: Multiple entry points (MS Windows)

On Sun, 26 Apr 2020 23:16:57 +0200, Oliver Betz wrote: > Are you running under real Windows or Wine? This doesn't sound like a > Windows issue. I've unzipped the files under Linux on a disk shared with Windows. On Linux, files like perl.exe and perl530.dll have permissions 0664 (rw-r--r--).

Re: Multiple entry points (MS Windows)

Hi Oliver, On Sat, 25 Apr 2020 00:07:35 +0200, Oliver Betz wrote: > Seemingly I'm not recognizing the advantage in using pp *in addition* to > InnoSetup. > > What is the point to use InnoSetup just to transport *one single exe*? The point is that typical Windows users can download and click a

Re: Filtering

Anyone? On Tue, 28 Apr 2020 20:36:33 +0200, Johan Vromans wrote: > By default PAR::Filter::PodStrip is applied to all modules. > This can be disables globally with PAR_VERBATIM=1 . > > Is it possible to disable this filter with --modfilter ? > > -- Johan

Alternative approach (Was: Re: message before unpacking)

The thread "message before unpacking" inspired me to take the time to write this down. Some time ago I was pointed at a different approach for packing perl packages. It turned out to work quite well. The basic idea is not unlike PAR/Packager (pp): gather all files needed and put them in a

Re: [rt.cpan.org #147034] use of DateTime module results in endless loop in pp

> Sorry, I can't reproduce this on Linux with Perl 5.32.1 and latest PAR > (1.018) and PAR::Packer (1.057). I can reproduce this in a Windows 10 VBox with perl 5.30, PAR 1.017 and PAR::Packer 1.056. Same after upgrading PAR to 1.018. It completes after upgrading pp to 1.057. -- Johan

[rt.cpan.org #132431] Implicit modules

Mon Apr 27 07:21:49 2020: Request 132431 was acted upon. Transaction: Ticket created by JV Queue: Module-ScanDeps Subject: Implicit modules Broken in: 1.27 Severity: Normal Owner: Nobody Requestors: j...@cpan.org Status: new Ticket

[rt.cpan.org #132431] Implicit modules

Mon Apr 27 13:46:59 2020: Request 132431 was acted upon. Transaction: Correspondence added by JV Queue: Module-ScanDeps Subject: Implicit modules Broken in: 1.27 Severity: Normal Owner: Nobody Requestors: j...@cpan.org Status: open Ticket