Re: From ActiveState to Strawberry Perl

On Fri, Dec 12, 2014 at 7:23 PM, Juan José 'Peco' San Martín jsanmar...@gmail.com wrote: After some analysis work, saw that in Strawberry I need to pass the parameter: -I lib -l libxml2-2_.dll to work with XML files. (not sure why it wasn't needed with ActiveState Perl :-?) It's probably

Re: From ActiveState to Strawberry Perl

On Sun, Dec 14, 2014 at 7:49 PM, Juan José 'Peco' San Martín jsanmar...@gmail.com wrote: The one that fails, it's little bit bigger (as expected) and includes these extra files that make the exe doesn't work /lib/auto/Digest:SHA /lib/auto/Net:DNS /lib/Digest:SHA.pm /lib/IO/Socket:INET6.pm

Re: From ActiveState to Strawberry Perl

On Sun, Dec 14, 2014 at 6:30 PM, Juan José 'Peco' San Martín jsanmar...@gmail.com wrote: Simple script to do wget: *use strict;use warnings;* *use LWP::UserAgent;* *my $browser = LWP::UserAgent-new();* *my $echo=$browser-get('http://google.com http://google.com');* *if (not

Re: From ActiveState to Strawberry Perl

On Mon, Dec 15, 2014 at 6:15 PM, Juan José 'Peco' San Martín jsanmar...@gmail.com wrote: I found that INET6 seems to be broken in some way. See this: https://rt.cpan.org/Ticket/Display.html?id=83967 Unfortunately it seems this ticket didn't result in a ticket for IO::Socket::INET6 to fix

Re: Problem with cache files being deleted

On Mon, Dec 15, 2014 at 9:15 PM, Kime Philip philk...@kime.org.uk wrote: ...regularly we get an error report from users that after a while using the tool, a particular file disappears from the cache and the cache has to be deleted and the binary unpacked again. I have never worked out why this

Re: Problem with cache files being deleted

On Tue, Dec 16, 2014 at 11:06 AM, Kime Philip philk...@kime.org.uk wrote: Certainly some cases were due to users Ctrl-Cing a first .exe run because they thought it was taking too long (normal for it to take longer on first run of a new version of course Sure - if the next run sees that the

Re: Problem with cache files being deleted

On Tue, Dec 16, 2014 at 11:29 AM, Shawn Laffan shawn.laf...@unsw.edu.au wrote: For the more general case, is there a simple means to trigger the re-extraction of all files packed using -a? Simply delete the cache area :) Sorry, for .pm and glue .dll files the check is automatic as PAR

Re: Problem with cache files being deleted

On Tue, Dec 16, 2014 at 12:16 PM, Shawn Laffan shawn.laf...@unsw.edu.au wrote: What I'm thinking of is some way for a PAR executable to detect if extra files packed using -a are missing, and then unpack them. Such a check would defeat the if the cache area exists, skip extracting stuff logic,

Re: Problem with cache files being deleted

On Thu, Dec 18, 2014 at 12:37 AM, Ron W ronw.m...@gmail.com wrote: So, my idea of inserting a BEGIN block, in the program.pl to be packaged, that adds files to %INC should work. Then run pp with the -c (or -x) option, then those files will be picked up by ScanDeps. And the packaged program.pl

Re: Problem with cache files being deleted

On Thu, Dec 18, 2014 at 12:18 AM, Shawn Laffan shawn.laf...@unsw.edu.au wrote: It boils down to checking for par_tmp/inc/MANIFEST and unzipping it if needed. None of the -a packed files are listed in the manifest, Ooops, that might be considered a bug... Cheers, Roderich

Re: Problem with cache files being deleted

Here are two other ideas for a workaround for some cleanup program purged some files in my cache area. The rearguard hack: - make sure extracted files get the timestamp of extraction, not the timestamp recorded in the zip archive - add a dummy file, say REARGUARD.txt, at the top of the

Re: Problem with cache files being deleted

On Thu, Dec 18, 2014 at 10:22 PM, Shawn Laffan shawn.laf...@unsw.edu.au wrote: The extractions currently use Archive::Unzip::Burst as the first attempt. I don't know its behaviour, but I assume that if some files exist and are locked then it will fail. It's also protected by the $inc.lock

Re: Prevent shared libs from being cached in memory on AIX

On Wed, Jan 21, 2015 at 5:00 PM, Tim Hoke th...@northpeak.org wrote: On AIX, when I execute my pp'd binary (pp -C) the shared libs remain loaded in memory. What do you mean by remain loaded in memory - even after the process created by executing the pp'd binary has exited? And why would

Re: Prevent shared libs from being cached in memory on AIX

I see, weird. Your patch looks reasonable, shouldn't break in other environments as cache files should be in a per-user tree anyway. Just a file bug on RT against PAR-Packer (because that's were I look first), the text of your original post should do. Cheers, Roderich

Re: Fix for PAR-Packer 1.024 with a nonstandard libperl.so name

On Fri, Jan 23, 2015 at 12:17 PM, Markus Jansen markus.jan...@ericsson.com wrote: It would be great to get it into the next PAR-Packer release. Thanks, patch looks good. Please submit a bug on rt.cpan.org against PAR-Packer (just so that it doesn't get lost), the body of your mail should

Re: Fix for PAR-Packer 1.024 with a nonstandard libperl.so name

On Fri, Jan 23, 2015 at 1:29 PM, Roderich Schupp roderich.sch...@googlemail.com wrote: Thanks, patch looks good. Please submit a bug on rt.cpan.org against PAR-Packer (just so that it doesn't get lost), Nevermind, I already applied the patch, will be in PAR::Packer 1.025 Cheers, Roderich

Re: Adding local directories to @INC for a pp executable

On Mon, Apr 20, 2015 at 11:05 PM, Harald Jörg harald.jo...@arcor.de wrote: So I thought that I could just use lib 'foo'; in my source, and then drop the plugins to directory 'foo'. To my disappointment, this fails, the modules aren't found. Drats. To my utter surprise, I got it working

Re: Adding local directories to @INC for a pp executable

On Tue, Apr 21, 2015 at 8:57 PM, Harald Jörg harald.jo...@arcor.de wrote: The DLLs are the notorious libeay32_.dll and ssleay32_.dll. I seem to recall having found an article of yours saying this can't be solved, but am unable to find the article right now. Of course it can be solved, but

Re: PAR + tmpwatch = mess

On Wed, May 13, 2015 at 12:00 AM, Shawn Laffan shawn.laf...@unsw.edu.au wrote: It could do with some review, Shawn, sorry for not having looked at this earlier: your patch doesn't solve the problem at all. It adds a canary file, alright, but the real problem is that Archive::Zip (method

PAR Subversion repositories [was: PAR + tmpwatch = mess]

On Tue, May 19, 2015 at 12:49 AM, Shawn Laffan shawn.laf...@unsw.edu.au wrote: Is there an alternate repo? svn.openfoundry.org has not been responding for the last 24 hours, perhaps more. Otherwise I'll wait for it to come back online to update my repo to the latest par sources before

Re: PAR + tmpwatch = mess

On Tue, May 19, 2015 at 12:49 AM, Shawn Laffan shawn.laf...@unsw.edu.au wrote: OK. I'll change it to update the mtime after extraction, and create the canary file at extraction time (which is simpler in any case). Note (this is mostly a reminder for myself, but other eyes are welcome): There

Re: PAR + tmpwatch = mess

On Tue, May 19, 2015 at 12:49 AM, Shawn Laffan shawn.laf...@unsw.edu.au wrote: svn.openfoundry.org has not been responding for the last 24 hours, perhaps more. Otherwise I'll wait for it to come back online to update my repo to the latest par sources before starting. The Subversion services

Fwd: PAR + tmpwatch = mess

On Fri, Jun 19, 2015 at 1:38 PM, Markus Jansen markus.jan...@ericsson.com wrote: I would not recommend the canary mode as a default, unless we have found that it is reasonable to do so. Why not? If a user is still invoking the packed executable once in a while, the canary avoids the situation

Re: PAR + tmpwatch = mess

On Mon, Jun 22, 2015 at 3:25 PM, Markus Jansen markus.jan...@ericsson.com wrote: My point was simply that the unpacking modification might break some code. Yes, let's break some code then :) Cheers, Roderich

Fwd: PAR vs MIME::Types

On Thu, Jun 11, 2015 at 8:09 PM, Philip Gwyn li...@artware.qc.ca wrote: To me, all libraries should allow the caller to specify where to find data files. That's a nightmare for admins and packagers... In fact File::ShareDir is a much better option then __FILE__ or %INC. What I would like to

Fwd: Code signing PAR follow-up

On Sun, Jun 14, 2015 at 8:41 AM, Daniel Caspi ddca...@gmail.com wrote: One thing in particular is that the code signature extends the length of the binary. It seems like the PAR executable has to end with \nPAR\n. Correct. The code signature needs to add characters at the end of this binary

Re: PAR vs MIME::Types

On Mon, Jun 15, 2015 at 7:31 PM, Ron W ronw.m...@gmail.com wrote: If I were going to make a change to PAR::Packer, I would be inclined to provide the packaged application with $ENV{PP_PERL_MIME_TYPE_DB} set to the packaged location of types.db so that the application could then decide where

Re: Par not working on Net::FTP::Recursive Script

On Sun, Aug 2, 2015 at 7:51 PM, Mike Flannigan mikef...@att.net wrote: The script uses this: Not enough information. For instance, how does it open a prompt box? Try cutting the script down to a minimal example that exhibits the problem. Cheers, Roderich

Re: Par not working on Net::FTP::Recursive Script

On Tue, Aug 4, 2015 at 12:33 AM, Mike Flannigan mikef...@att.net wrote: Thanks for confirming that. Chomp certainly doesn't fix the problem. chomp won't help, in my example it will only get you from $VAR1 = [ foo\r\n, bar\r\n, quux\r\n ]; to $VAR1 = [

Re: Par not working on Net::FTP::Recursive Script

On Sat, Aug 8, 2015 at 2:42 PM, Shawn Laffan shawn.laf...@unsw.edu.au wrote: After a bit more thought, the whole process might be simplified by adding the :crlf layer to the DATA handle in your code. This is set by default on windows, but not on linux. That should also help when you move

Fwd: PAR Subversion repositories [was: PAR + tmpwatch = mess]

On Tue, Jul 21, 2015 at 12:59 AM, Shawn Laffan shawn.laf...@unsw.edu.au wrote: Has there been any decision on the repo location? The repo for the PAR ecosystem will stay at OpenFoundry. I updated the repo URLs in all META.yml files accordingly. Thanks also for implementing the cache

Re: Problem with Par:Packer?

I suppose you are using the latest version of Module::ScanDeps? If so, please downgrade to the previous version of M::SD (as a temporary workaround) and check whether the problem persists. Note that I won't have time to investigate until at least Tuesday. Cheers, Roderich

Re: update one file without par?

On Oct 23, 2015 17:13, "Robert Davis" wrote: > > is there an option for pp. > Can I use the cygwin pp to update a exe created from strawberry? Nope. Cheers, Roderich

Re: Problems with Tkx in par package

On Sun, Sep 20, 2015 at 11:14 PM, Kevin Walzer wrote: > my $frameworkpath = "$Bin/Tcl/bin/tcl86.dll"; The value of $FindBin::Bin is probably not what you think it is: it's the directory containing the packed executable, not the directory in the cache area that

Re: Problems with Tkx in par package

On Mon, Sep 21, 2015 at 5:26 AM, Kevin Walzer wrote: > These flags seem to be ignored. Same behaviour as in the unpacked script: temporarily rename the top level directory of your Tcl installation and run your script - it won't work, no matter what PERL_TCL_DL_PATH is set

Re: Can't extract par archive

On Mon, Dec 14, 2015 at 1:28 PM, RAPPAZ Francois wrote: > “7-Zip now checks only first 4 MB for zip headers. > > But that archive contains some big sfx-stub that is larger than 4 MB. > > Why does it add 4 MB win32 PE Executable STUB to zip archive?” > Because it can :)

Re: Can't extract par archive

Hi Francois, sorry I didn't revecive your post below via the mailing list. I have moved from PAR v. 1.012 to 1.025 when I reinstall a new version of > my strawberry perl. I recently used pp for a simple script and the > resulting exe was ok. Now I'm trying to reproduce a series of steps to >

Re: [perl5-porters] reworked context stack system

On January 8, 2016 10:53, Steffen Mueller wrote in perl5-porters: Picking out one of the failures: > On 01/07/2016 09:59 PM, Andreas Koenig wrote: > > - RSCHUPP/PAR-Packer-1.028.tar.gz > > > >main.o: In function `par_redo_stack': > > >

Re: Getting Gtk3 to work with PAR

On Mon, Jun 13, 2016 at 11:31 PM, Zakariyya Mughal wrote: > $ objdump.exe -ax > "C:\msys64\tmp\par-7a616b69\cache-b75d584224b1a1061779c0bb91d380c83ae4a68e\79d2d23b.dll" > | grep "DLL Name" > ... > DLL Name: Cairo.dll > DLL Name: Glib.dll

Re: Getting Gtk3 to work with PAR

On Mon, Jun 13, 2016 at 9:54 PM, Zakariyya Mughal wrote: > I notice that there is a similar issue > that was opened > in 2010 for a Gtk2 program. > > More relevant might be the thread on the par mailing list starting

Re: Re: segmentation fault when running a script generated with pp on another unix server

On Tue, Jun 21, 2016 at 8:43 AM, kadimir kasprzak wrote: > I've executed both exe with truss and compared the result with a tool like > WinMerge. > > I don't know if it's relevant, but it seems that the issue appear with the > module Zlib (when tyring to uncompress the

Re: segmentation fault when running a script generated with pp on another unix server

On Sat, Jun 18, 2016 at 8:37 PM, kadimir kasprzak wrote: > i got a segmentation fault (core dump). > > Do you have an idea on what could be the reason of this issue ? > Not enough information for even an idea. Does this also happen for a packed "hello world" script,

Re: --tempcache

On Mon, Feb 8, 2016 at 8:21 AM, Juan José 'Peco' San Martín < jsanmar...@gmail.com> wrote: > With --tempcache the user is able to change the name. > If by "user" you mean "the person creating the packed executable", yes, but that is not what you want. > Is it possible to set the full route? >

Re: PAR::Packer taking too long to convert

On Wed, Mar 16, 2016 at 2:01 AM, Juan Mejia wrote: > looks Ok except that it has been running for more than 30 minutes and > haven’t got any results yet. > > > Try a "hello, world" example: pp -o hello.exe -e "print qq[Hello, world\n]" If this works (should take only a

Re: Use of uninitialized value in do “file” at “path” PAR.pm line 636

On Fri, Apr 22, 2016 at 4:25 AM, Vinay Gudisagar wrote: > Please help solve this issue > > Use of uninitialized value in do "file" at "path" PAR.pm line 636 I can't reproduce this. Also the script as given will not even run: Global symbol "$hostname" requires explicit

Re: Use of uninitialized value in do “file” at “path” PAR.pm line 636

On Fri, Apr 22, 2016 at 4:25 AM, Vinay Gudisagar wrote: > "Use of uninitialized value in do "file" at > HOMEPATH/perl_modules/lib/site_perl/5.14.2/PAR.pm line 636" strong text This warning is harmless and seems to be caused by a quirk in Perl 5.14. It is _not_ caused by

Re: PAR::Packer::VERSION

On Thu, Jun 30, 2016 at 3:26 PM, Johan Vromans wrote: > 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. > $PAR::Packer::VERSION is not

Re: Shared double?

On Thu, Jun 30, 2016 at 7:08 PM, Johan Vromans wrote: > > Is this intended behaviour? 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) - small changes have unforeseen consequences in other parts. The shared

Re: Shared double?

On Fri, Jul 1, 2016 at 8:21 AM, Johan Vromans wrote: > Hmm. This smells like PAR is factually a discontinued product. > Would you call your Getopt::Long a "product"? The PAR ecosystem is certainly not discontinued, it's being used and I intend to support it, just check the

Re: Including shared libraries

On Wed, Jun 29, 2016 at 11:49 PM, Johan Vromans wrote: > pp executables are not as stand-alone as the ones from Cava and > PerlApp. > Care to elaborate? Cheers, Roderich

Re: Including shared libraries

On Wed, Jun 29, 2016 at 7:27 PM, Johan Vromans wrote: > 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.

Re: Including shared libraries

On Sat, Jul 2, 2016 at 3:04 PM, Johan Vromans 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. > There are functions

Fwd: Updating PAR executables

On Tue, Mar 14, 2017 at 12:49 PM, Johan Vromans wrote: > I have a perl application that consists of pure perl modules only. Are you sure that your pure perl modules don't require (directly or transitively) something platform dependent, e.g. IO.pm (which is an XS module)?

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

On Jul 28, 2017 5:29 PM, "Hou, Ying" wrote: The good thing is we do have Microsoft visual studio version 10, do you know how to make use it? In theory it should work out of the box if it's C++ compiler is on the PATH. Unpack the PAR::Packer tarball, change into the top level

Re: PAR:PAcker 1.037 installtion issue

On Fri, Aug 11, 2017 at 10:57 PM, Hou, Ying wrote: > Can't locate PAR/Heavy.pm in @INC (you may need to install the PAR::Heavy > module > > ) (@INC contains: ..\blib\arch ..\blib\lib C:/Perl64/site/lib > C:/Perl64/lib . .) > > at -e line 268, <_FH> chunk 1. > > system(boot.exe

Re: par-packer-1.037 installation issues

On Jul 27, 2017 5:34 AM, "Hou, Ying" wrote: There are a lot of versions of dmake and MinGW, do you happen to know a version you would recommend? Since you're using ActiveState Perl, simply install their PPM package MinGW. Cheers, Roderich

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

On Thu, Jul 27, 2017 at 4:31 PM, Hou, Ying wrote: > As long as there is a MinGW which works for my activestate perl 5.20, I > have no preference for version numbers. > Actually, you don't specifically need Mingw - you need a C or C++ compiler to build PAR::Packer. Usually

Re: LWP::Protocol::https

On Fri, Jul 21, 2017 at 2:29 PM, RAPPAZ Francois via par wrote: > Run on a pc without perl installed I'm getting the error > > Error GETing https://services.rero.ch/item/1001528198/rero-number: Can't > load 'C:\Users\zinaouih\AppData\Local\Temp\par-7a696e616f756968\ >

Re: LWP::Protocol::https

On Tue, Aug 22, 2017 at 9:55 AM, RAPPAZ Francois via par wrote: > My verions of perl is 5.24, > > PAR::Packer : 1.037 > > Module::Scan::Deps: 1.22 > > > > Running > > U:\>objdump -ax C:\strawberry\perl\vendor\lib\auto\Net\SSLeay\SSLeay.xs.dll > | grep "DLL Name" > > gives > >

Re: cross platform question for PAR::Packer

On Wed, Sep 13, 2017 at 7:50 PM, Hou, Ying wrote: > Thanks for your great help and I was able to install PAR::Packer which > generate a standalone binary on Windows. > > Since the binary is generated on Windows, it can only run on Windows where > no Perl was installed. > >

Re: LWP::Protocol::https

On Wed, Aug 23, 2017 at 8:21 AM, RAPPAZ Francois wrote: > I was using –I path_to_the_dll/foo.dll (upercase i) instead of –l (lower > case l) to include the dll… > Arrggh, sans serif fonts strike again! Cheers, Roderich

Re: Problem with packing on OSX

On Mon, Nov 6, 2017 at 12:09 AM, Kime Philip wrote: > Reason: Incompatible library version: 79628e8f.bundle requires version > 12.0.0 or later, but libxml2.2.dylib provides version 10.0.0 at > /loader/HASH(0x10188cc08)/DynaLoader.pm line 197. > > These version numbers

Re: Problem with packing on OSX

On Mon, Nov 6, 2017 at 9:35 PM, Kime Philip wrote: > Checked all that. It seems what is happening is that the bundle is failing > to find the packed libxml2, which seems to be in: > > /inc/shlib/darwin-thread-multi-2level/opt/local/lib > > That looks wrong, in the packed

Re: Pod::Usage and PAR packaged binaries

On Wed, Nov 8, 2017 at 1:46 PM, Johan Vromans wrote: > Has anyone already figured out how this can be made to work? > I'm guessing that you have a separate .pod file instead of inline pod? A clumsy way would be to explicitly add the .pod with --addfile, then locate it

Re: Adding to Module::ScanDeps %Preload?

On Fri, Aug 31, 2018 at 6:32 PM Harald Jörg wrote: > I could prepare a Pull Request, Sure. But I just commited these :) https://github.com/rschupp/Module-ScanDeps/commit/7ceb274d85ee7725e444674af3e35e644b6bd3b3 (for HTTP::Entity::Parser)

Re: Adding to Module::ScanDeps %Preload?

On Sat, Sep 1, 2018 at 3:09 PM Harald Jörg wrote: > "=> 'sub'" actually does what I hoped it would do :) > 'Foo/Bar.pm' => 'sub' means: add anything below .../Foo/Bar/ as dependency (and scan these modules, too) where "..." loops over all of @INC. It's similar to pp's option "-M Foo::Bar::".

Re: PAR::Packer issue finding GD module in Win64 environment

On Tue, Apr 17, 2018 at 1:07 AM, Charles Myers wrote: > Transfer use_GD.exe to clean Win64 environment (no perl, no libs). > Executable is unable to find GD or perhaps a requirement of GD with > following error: > > Can’t load >

Re: DynaLoder and names of Gtk2 dlls

On Tue, Feb 26, 2019 at 12:30 PM RAPPAZ Francois via par wrote: > I’m hitting a wall with a recent strawberry perl setup, where all the > dlls during modules installs are named foo.xs.dll. Would that be a reason > why it fails, DynaLoader searching for foo.dll > > > No. Actually, DynLoader

Re: Installing PAR::Packer

On Thu, Feb 21, 2019, 10:38 RAPPAZ Francois via par wrote: > I would like to install it on Strawberry perl portable : > strawberry-perl-no64-5.20.3.3-32bit-portable > > > > The Windows defender has been unblocked, the compile pass, but not the > tests: first tests gives > > > > t/20-pp.t

Re: Installing PAR::Packer

On Fri, Feb 22, 2019, 08:28 RAPPAZ Francois wrote: > From a CPAN shell, I did install PAR ::Packer > See cpan's option "recommends_policy". Cheers Roderich >

Re: Gtk2 + PAR::Packer version

On Fri, Mar 1, 2019 at 8:09 AM RAPPAZ Francois via par wrote: > Idea someone ? > What are you trying to achieve? This looks like a pointless exercise to me. Cheers, Roderich

Re: use Glib -> crash

On Fri, Feb 8, 2019, 09:06 RAPPAZ Francois Adding Glib.xs.dll to my list does not change the problem: same error > Shawn was correct that they should not be added with --lib. Also they should be automatically detected, if not that's a bug. > Using pp_autolink.pl without any other file added

Re: packing Gtk2 scripts

ows path I have C:\prog\gtk+\bin. C:\prog\gtk+ is where I > unzipped the Gtk2 stuff. > > > > > > Shawn, was it your trimmed down script (reduced to use Glib; ) that worked > for you, or is it the longer script displaying the Gtk2 windows ? > > The first works fo

Re: Codesign macOS executable created pp

On Fri, Apr 12, 2019 at 11:34 PM welle Ozean via par wrote: > I need some help with the following issue. I need to codesign my macOS > .app containing an executable created with pp. Unfortunately code signing > fails with the error 'main executable failed strict validation' > It's helpful to

Re: Problem with macOS executable

On Sat, Jun 15, 2019 at 11:49 AM Oliver Betz wrote: > On Fri, Jun 14, 2019 at 8:40 PM welle ozean via par wrote: > By the way, why is the application trying to call something in > "Users/we/perl5/perlbrew" which is a path in the machine where I > compiled the application? > > > this is likely a

Re: Using PAR_GLOBAL_TEMP prevents library updates

On Wed, May 8, 2019 at 9:47 AM Oliver Betz wrote: > when I use PAR_GLOBAL_TEMP, new versions of the application don't > overwrite existing libraries. > > For example, running a new version of ExifTool (for Windows) will fail > then because the libraries of the old version are kept. > > I need

Re: Running program from uncompressed directory tree

On Tue, May 7, 2019, 18:09 Oliver Betz wrote: > > how can I run a program directly from the *unpacked* file tree? > TL;DR You can't I just want to use PAR to bundle all dependencies to get a "portable" > Perl based Windows application, with dedicated unpacking instead of the > automatic

Re: Running program from uncompressed directory tree

On Wed, May 8, 2019 at 9:42 AM Oliver Betz wrote: > ... Consider a widespread program > like ExifTool: Malware can easily find the runtime files and infect them > without elevated rights. > So what? The Windows standards suggest to make exectuables write protected. > > Bullshit advice. If the

Re: What is the patch in XSLoader.pm good for?

On Fri, Jul 12, 2019 at 5:32 AM Oliver Betz wrote: > PatchContent.pm has an entry for XSLoader.pm: > ... > What is it good for? > Good question, I dunno. Unfortunately the commit log that added this entry was lost 13 years ago, so that won't help either. It's effectively useless, as XSLoader.pm

Re: Par with strawberry-Perl

On Sat, Apr 25, 2020 at 1:44 AM Shawn Laffan wrote: > There are likely missing DLLs that need to be added to the pp call using > the --link option. > > For Net::SSH2 these DLLs are probably: - libssh2*.dll - libz*.dll - libgcrypt*.dll - libgpg-error*.dll The last two may be different if the

Re: Multiple entry points (MS Windows)

On Fri, Apr 24, 2020 at 2:36 PM Johan Vromans wrote: > But on Windows it matters whether the program is built with --gui or not. > If I build with --gui invoking the command line version will make all > terminal output disappear. If built without --gui the GUI invokation will > show a nasty

Re: Search path for libraries

On Tue, Apr 28, 2020 at 8:39 PM Johan Vromans wrote: > The packer has a --lib parameter to set the module search path. > Is there something similar for shared libraries? > No. In case you're wondering in which directories "--link foo" (where "foo" is just a name, not a path) searches for

Re: message before unpacking

On Mon, Jan 18, 2021 at 9:53 PM Robert Eden wrote: > Checking the mailing list archives, this was discussed in CPAN ticket > 8846, but no real resolution. > What ticket 8846? > Is there any hook to do this? > No. Your main script will only start executing once all files are unpacked.

Re: How to reset ENV

On Thu, Feb 24, 2022 at 9:59 AM Patrick Böker wrote: > Rakubrew can act as a shim wrapper that forwards its call to other > programs. > I consulted the rakubrew.org page, but failed to understand the shim mode. What does it do? And what role plays the PAR packed rakubrew executable in "forwards

Re: How to reset ENV

On Thu, Feb 24, 2022 at 12:07 PM Patrick Böker wrote: > Did I understand correctly, that you also have no better idea than > heuristically trying to bring ENV back to its original state right before > doing "exec"? > It's the right idea. Also no heuristic needed: my $ldlibpthname =

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

On Sat, Mar 11, 2023 at 9:32 AM Johan Vromans wrote: > 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. > Hi Johan, thanks for testing. PAR::Packer 1.056 was a bad one

Re: Packed executable exit code 1 issue

On Mon, Jul 17, 2023 at 7:56 AM Deepak Khosla via par wrote: > == > use strict; > use warnings; > my $exit_code = $ARGV[0]; > print "called with $0 $exit_code\n"; > > END { > $? = $exit_code; # Setting this in case exit is ignoring our exit_code > print STDERR

RE: DATA or -a

Sorry, if I selected a wrong address. It's the correct one :) The next attempt was with -a option: pp -B -a dir.tar.zip -o new_script new_script.pl #!/sne/perl/bin/perl system unzip -p dir.tar.zip | tar xf -; ... The problem is: I don't know the path of my dir.tar.zip when

RE: Builduing PAR under CygWin?

PS: the error message I now get: main.o:main.c:(.text+0x67): undefined reference to `_boot_' collect2: ld returned 1 exit status This undefined reference is caused by a superfluous blank in /usr/lib/perl5/5.8/cygwin/Config_heavy.pl: ... static_ext=' Win32CORE' ^ ... Removing

RE: Builduing PAR under CygWin?

Malcolm Nooning wrote: The -v problem may get better or worse with this fix. The file automated_pp_test.pl already uses POSIX uname to get the $os, so please try making the change below. my $_out = $Config{_exe} || '.out'; if ($os =~ m/CYGWIN/i) { $_out = '.out'; } Thanks for

RE: LWP::User agent vs PAR

I wonder how to compile such small script using PAR to make it work: #!perl use warnings; use strict; use LWP::UserAgent; my $ua = new LWP::UserAgent; my $req = new HTTP::Request(GET = 'http://www.google.com'); my $res = $ua-request($req); if

RE: par requires disk space in /tmp ?

and on both systems the commands pp or par or running resulting executables, will take some space in /tmp. the files there will not be removed. i set the env variable PAR_TEMP to /usr/tmp with no effect. PAR_TEMP is used by the pp'ed application to know where it has been extracted to (e.g.

RE: PAR 0.92 preflight

it's time for another PAR release. Primarily because the SIGNATURE of the 0.91 release was broken. I'm really sorry for that mistake. You can find the preflight version at http://steffen-mueller.net/tmp Please test and report your findings to me directly or as an answer to this post.

RE: just a pebcak ? or something more .. PAR 0.92

From: Eadon, Bryant [mailto:[EMAIL PROTECTED] ./par -I/home/beadon1/build/PAR-0.92/inc -I/app/gmd/pm -I/home/beadon1/perl587/lib/5.8.7/sun4-solaris-thread-multi -I/home/beadon1/perl587/lib/5.8.7 -I/home/beadon1/perl587/lib/site_perl/5.8.7/sun4-solaris-thre ad-multi

RE: problems with Scalar::Util

I'm trying to create a packed exe to deploy on windows servers. Build as 'pp -o file.exe script.pl' . Builds fine, but when I run it I get: Following up my previous mail: Did you build pp.exe from the same version of perl and Scalar::Util that is now on the machine you are packing script.pl?

RE: Caching additional files

The parl.exe executable is stored on the local users pc. The .par file is stored on the network drive. Due to security issues, .exe files are not allowed on the network drive. The files are being cached on the local users pc under c:\documents and settings\{user}\local

RE: problems with Scalar::Util

You are right on. The packed exe has version 1.07, and the script is written, and using 1.18. Now, if only I can get it to use 1.18 use Scalar::Util 1.18 qw/refaddr/ doesn't seem to work Oddly, when I unzip the exe that I have created with pp, the 1.18 version is actuall in the

RE: Exclude core modules from executable?

Is there a reasonable way to turn off -B in pp to make a nearly- standalone executable? I'm working on a specialized app that will run only on MacOSX 10.4, and therefore is guaranteed to have Perl 5.8.6 installed. I'd like to shrink my multiple 5 MB executables by using the system

RE: PAR::Lipo?

Is there documentation somewhere of what comprises the non-ZIP portion of a PAR standalone executable and/or a PAR standalone script? http://search.cpan.org/~smueller/PAR-0.94/script/par.pl#Stand-alone_exec utable_format Most importantly: besides the ZIP portion, does the PAR exe

RE: Problems with use diagnostics;

[cc'ed the Module:ScanDeps maintainer, see below] When I do the following on Windows: pp -v -o out.exe -e use diagnostics; and then run .\out.exe, it gives the following error message: No diagnostics? at diagnostics.pm line 429. Compilation failed in require at script/ppCTAFk.pl line 1.

<    1   2   3   4   5   6   7   8   9   >