Following up on my previous post:
- JSON::XS needs "attributes.pm" which can't be autodetected.
We could add a special rule to Module::ScanDeps for this.
But as it turns out, "attributes.pm" is another one of those modules
that might be implicitly require'd by the Perl runtime itself
(lik
On Mon, May 17, 2010 at 10:35 AM, Daniel Lemke wrote:
> However, I wonder if there's anything like --use in PerlApp, where you can
> specify another executable so the new executable is only packed with modules
> that aren't already packaged in the executable you specified in --use.
There's no s
On Mon, May 31, 2010 at 11:14 AM, Developer wrote:
> I wanted to use 'pp' to build an "executable" for a little XML::RPC-Server
> using module RPC::XML::Server on a linux/debian server. Unfortunately I get
...
> Can't call method "parse" on an undefined value at
> blib/lib/RPC/XML/Server.pm (autos
On Mon, May 31, 2010 at 5:48 PM, Developer wrote:
> Thanks for the quick response. It works. :-)
Thanks for confirming this.
FYI: I just committed a special rule to Module::ScanDeps so that it will pick up
RPC::XML::Parser::XXX automatically whenever it sees RPC::XML::ParserFactory.
So the worka
On Wed, Jun 2, 2010 at 3:58 PM, Steffen Mueller wrote:
> b) Just compressing libperl roughly halves the size of the resulting Hello
> World executable.
Yes, I did some experiments, too :)
> We could save even more if we had to include another library (cf. the recent
> bug report).
Though libgcc
On Wed, Jun 2, 2010 at 3:38 PM, Ramesh K wrote:
> I have installed PAR by using *PPM install PAR* command. And I have ensured
> the PAR version by using *perl -MPAR -e "print
> PAR->VERSION.qq{\n};"*command which also gave the version as 1.000.
>
> After that i tried to create a exe by using comma
On Thu, Jun 3, 2010 at 6:11 PM, Razvan wrote:
> Is this fix included in pp 0.992? Because I get the following on OS X
> (perl 5.10.0):
The problem (and fix) is in Module::ScanDeps, not in PAR::Packer.
And M::D hasn't had a release since the fix went in.
BTW - at least in Linux, but probably on O
Folks, a bug tracker is NOT a discussion forum. Esp. if replying to a resolved
bug will automatically re-open the bug (as is the case for rt.cpan.org).
PLEASE continue this discussion on the PAR mailing list par@perl.org
> How did you run dmake twice?
>
Go into the toplevel source directory and
ntioned I use Strawberryperl so dmake is what I use.
>
> Regards.
>
> On Tue, 8 Jun 2010 07:14:40 -0400
> bug-par-pac...@rt.cpan.org ("Roderich Schupp via RT") wrote:
>
>> Tue Jun 08 07:14:39 2010: Request 57852 was acted upon.
>> Transaction: Corresp
On Wed, Jun 9, 2010 at 7:20 PM, Xaero wrote:
> You should read the pp pod which has a lot of useful options, infact if you
> have a few minutes then there is some fantastic documentation in the
> PAR-Packer tarball contrib folder by Alan Stewart.
You mean contrib/docs/{where_is_it,who_am_i}.txt
On Thu, Jun 10, 2010 at 12:00 PM, Ulli Horlacher
wrote:
> Instead of
>
> "This application has failed to start because libeay32_.dll was not found."
>
> I get
>
> "This application has failed to start because libssl32_.dll was not found."
>
> One step further!
>
> Then I copied libssl32_.dll, to
On Thu, Jun 10, 2010 at 1:41 PM, Steffen Mueller wrote:
> You didn't? Wow! It really needs better advertisement then. contrib/ has a
> bunch of useful things. Did you ever add your extraction script there?
_You_ added it :)
> The one gripe I have with the document is that it's talking about the
On Fri, Jun 11, 2010 at 9:30 AM, Xaero wrote:
> I was wondering if there was any other way to compress exe's genereated by PAR
First of all, if you're generating an exe then we are talking about
PAR::Packer, not PAR.
An exe - as generated by pp - consists actually of a fixed part (i.e.
it's the s
> I have seen directory /tmp/par-$user and /var/tmp/par-$user. Any reason for
> this.
Setting of the TMPDIR environment variable?
Cheers, Roderich
>
On Mon, Jun 14, 2010 at 11:51 PM, Rishi Mutnuru
wrote:
> I checked that source code is always referring to /tmp for TMPDIR.
To what source are you referring?
> Any reason for creating the directory /var/tmp/par-root?
PAR::Packer tries (cf. par_mktmpdir() in myldr/mktmpdir.c)
PAR_GLOBAL_TMPDIR,
On Wed, Jun 16, 2010 at 8:20 PM, Rishi Mutnuru wrote:
> While the /tmp is full, I observed that pp is throwing error that “ / full,
> write failed”.
>
> Won’t that switch to /var/tmp incase /tmp is full?
No.
Cheers, Roderich
On Thu, Jun 17, 2010 at 10:21 PM, Rishi Mutnuru
wrote:
> I observed that pp built out of PAR-0.90 is extracting the directories in
> /tmp where as PAR-1.005 in /var/tmp.
Fist of all, your talking about PAR::Packer (currently at 1.005) here,
*not* about
PAR (currently at 1.000).
> Is it expected
On Thu, Jun 17, 2010 at 2:57 PM, Trappe, Jens (EXTERN: ITHUD)
wrote:
> I have problems with a PAR-generated executable using the modul Aspect (AOP).
>
> I compiled aop_test.pl with "pp -o aop_test.exe aop_test.pl". If I use the
> compile-script
> (see later), the same problem occurs.
First of al
On Sun, Jun 20, 2010 at 11:45 AM, Developer wrote:
> I am using a 32-bit Debian Linux for development and would like to deploy on
> the same linux but for the 64-bit variant. What do I have to take in mind?
Given you have the necessary system libraries (libc, zlib etc) in 32-bit
on the target mac
On Fri, Jun 18, 2010 at 4:22 PM, Trappe, Jens (EXTERN: ITHUD)
> I'm sorry, but the exe packed by pp -x -o ... is NOT working.
Can't reproduce this here (Linux, Perl 5.12.1, PAR::Packer 1.005, PAR
1.000, Aspect 0.90).
No fancy "compile" script needed, simply
pp -o aop_test.exe aop_test.pl
did the
On Sun, Jun 20, 2010 at 11:29 PM, Developer wrote:
> Please tell us the version of perl, PAR and PAR::Packer (on the 32-bit
> build system).
>
> I have used perl 5.10.0, PAR 1.00, PAR::Packer 1.004
That's what I thought when I read "incompatible 64-bit IO.so":
PAR::Packer doesn't work on Perl 5.1
On Mon, Jun 21, 2010 at 11:35 AM, Trappe, Jens (EXTERN: ITHUD)
wrote:
> I use ActivePerl 5.10.0.1004
Hi Jens,
FYI (but that's not related to your current problem):
Note that PAR::Packer doesn't work on Perl 5.10.0 - that version
of Perl broke PAR::Packer's method to intercept the loading
On Thu, Jul 1, 2010 at 5:32 PM, Zico Zicaus wrote:
> i have problem whit use pp, when i try to compiled source .pl in .ex this is
> ok, but when i launch the command for add information on file exe, i get
> error:
>
> C:\Perl\produzi\Annulli_Tecnici\bin>pp -N Comments=ciao -o
> Annulli_Tecnici.
On Tue, Jul 13, 2010 at 1:32 AM, scott miller wrote:
> After having recently built a brand new version of 5.8.9, I'm having trouble
> getting PAR::Packer installed. Compilation consistently fails at static.c
> with:
>
> catastrophic error: The compiler has run out of memory; terminating the
> com
On 13.07.2010, at 18:41, scott miller wrote:
> Still failing with the same error. myldr/par is sitting at about 4.2 MB.
Maybe the compiler can't grok static initializers this large?
Try the following: go into myldr. The my_*.c files you see there contain
several large strings or char arrays. On
Scott wrote
> myldr/par is sitting at about 4.2 MB.
Why is that so large? It should be about the size of your perl executable
(because it is actually a special purpose Perl interpreter).
Cheers, Roderich
On Wed, Jul 14, 2010 at 12:30 AM, scott miller wrote:
>>> myldr/par is sitting at about 4.2 MB.
>>
>> Why is that so large? It should be about the size of your perl executable
>> (because it is actually a special purpose Perl interpreter).
>
> Very good question, that is also the size of my perl b
On Sun, Aug 29, 2010 at 4:54 AM, Chia-liang Kao wrote:
> This is because Check.dll is refered by name on win32, and this
> is probably the case of all modules exporting c-symbols for other
> xs modules.
... a practise which I consider abuse. Fortunately it seems to
only have spread to a few area
On Wed, Sep 1, 2010 at 6:23 AM, Hrisheekesh Kale
wrote:
> I have installed PAR packer on my windows XP machine. The installation seems
> to have gone alright.
Did you run the test suite ("dmake test" or perhaps "nmake test")?
If yes, did any tests fail?
Cheers, Roderich
On Wed, Sep 8, 2010 at 10:24 PM, philkime wrote:
> using pp to package a binary which uses Unicode::Collate. This module
> requires some data files in its main library (that is, in /
> Unicode/Collate/ and I add these with the -a flag. This works fine. On
> OSX however, when Unicode::Collate tries
On Thu, Sep 9, 2010 at 11:33 AM, Philip Kime wrote:
> Greetings and many thanks - this fixes the problem.
Thanks for confirming that it fixes your problem, too.
> Do you know when the next version of PAR::Packer with this fix will be
> released?
I just uploaded 1.007 to CPAN... :)
Cheers, Rod
On Wed, Sep 15, 2010 at 9:04 PM, philkime wrote:
> When I built with the 5.12 pp, the cache for my binary contains
> libperl.so.5.10 and not libperl.a. I even tried deleting all the
> libperl.so* from the machine and it still appears in the cache when I
> run the binary! Where does pp get its libp
On Thu, Sep 16, 2010 at 11:37 AM, Philip Kime wrote:
> Thanks - I managed to work this out eventually - the problem seems to
> be that on Linux where libperl.so is usually in /usr/lib, this gets
> picked up by the install even if it's not the right libperl for the
> perl you are building with.
Ye
On Thu, Sep 23, 2010 at 3:14 AM, Sisyphus wrote:
> But if it's a matter of getting the failing test to pass, then that's
> something else. I tried to put some diagnostic messages into
> contrib/automated_pp_test.pl and then re-run 'perl -Mblib t/20-pp.t', but
> inc/Test/Builder.pm won't let me do
On Tue, Oct 19, 2010 at 8:49 AM, Johannes Kilian wrote:
> I'm trying to pack an executable on a Windows system - deep inside my
> code a dependent module uses socket.pm.
>
> Packing my sourcecode using pp I get an executable. Starting this
> executable, I got the following error message:
>
> "Can'
On Tue, Oct 19, 2010 at 1:45 PM, Steffen Mueller wrote:
> While it'd be nice to do the user-friendly thing and warn about such issues
> whereever possible, I don't think this is a PAR bug. Loading a module using
> the wrong name is an accidental "feature" of the module loading mechanism.
>
> I vot
On Wed, Nov 17, 2010 at 4:16 AM, Ryan A wrote:
> completely new to perl here and wanting to use PAR::Packer to generate
> a stand-alone of my app for use on a remote machine. i've stumbled my
> way through the install of PAR and PAR::Packer successfully, i think.
>
> to install:
> cpan> make insta
On Sat, Dec 18, 2010 at 8:42 PM, Martha_em wrote:
> My computer uses Win7 with a x64 architecture.
> But I would like to generate Win32 executables.
> Is it possible without re-installing everything?
No, sorry - even if one would solve the puzzle to pack to 32 bit executables
using a 64 bit Perl,
On 29.12.2010, at 16:50, vijay wrote:
> perl -m CPAN - eshell
>> install PAR::Packer
>
> Resulted in
> C:\strawberry\perl\bin\perl.exe -e "chmod(oct('0444'), '..\blib\lib\PAR
> \Stripped
> PARL\Static.pm');"
> C:\strawberry\perl\bin\perl.exe run_with_inc.pl par.exe -I../blib/lib -
> q -B -O.
On Mon, Jan 3, 2011 at 7:34 AM, Ani Taggu wrote:
> When the exe file created by par packer for the code below is executed, it
> dies.
Very little information here to diagnose th problem:
- What does "it dies" mean - the process crashes, no error message?
- Please run the script with a minimalis
On Mon, Jan 3, 2011 at 7:20 PM, Ani Taggu wrote:
> (b) For the bug.xml file mentioned in the earlier post, everything
> works correctly if I do this:
> perl myapp.pl <--- OK no problem.
>
> However, if I do
> pp -o a.exe myapp.pl
> .\a.exe
> the
On Sun, Jan 23, 2011 at 10:08 PM, James Bowery wrote:
> ~/ncgi-bin$ cat t.pl
> use Hash::Case::Lower;
> tie my(%lchash), 'Hash::Case::Lower';
> $lchash{StraNGeKeY} = 3;
> print keys %lchash; # strangekey
> ~/ncgi-bin$ pp -M Hash::Case::Lower t.pl
Note that "-M Hash::Case::Lower" isn't necessa
On Mon, Jan 24, 2011 at 3:53 PM, Roderich Schupp
wrote:
> Looks more like a problem of Log::Report (which is "use"d by
> Hash::Case::Lower).
Further investigation shows that Log::Report::Dispatcher "require"s some
Log::Report::Dispatcher::$foo with $foo computed at im
On Fri, Feb 11, 2011 at 2:14 AM, Michael Miller wrote:
> I’m having trouble using the par packer and was wondering if someone could
> give me some direction.
> Below is a screenshot of the error I’m getting:
Please don't post screenshots (unless your problem really is the
graphic appearance),
as
On Fri, Feb 11, 2011 at 5:48 PM, Michael Miller wrote:
> I'm still having trouble and need some more advice. I created a simple
> testy.pl script with the following in it:
>
> use Digest::SHA;
> print "Hello world";
>
> When I run "perl testy.pl" I get "Hello world" printed to the console. So it
On Fri, Feb 11, 2011 at 6:23 PM, Michael Miller wrote:
> I tried:
>
> pp -B -P -o packed.pl testy.pl
"pp -B ..." is pretty broken and probably won't get fixed anytime soon :(
> As far as my goal, is PAR-Packer the answer or am I complicating things.
No, PAR::Packer is the way to go if you want
On Mon, Feb 14, 2011 at 12:01 AM, Michael Miller wrote:
> On the target machine, I copied the testy package and when I run it I get the
> following error:
> Dynamic linker : ./testy : could not open
> /usr/lib/perl5/5.8/i586-pc-sco3.2v5.0/CORE/libperl.so
>
> I'm assuming this means I need to inc
On Mon, Feb 14, 2011 at 3:16 PM, Michael Miller wrote:
> Then I ran 'make' and got:
Hmm, looks good. If you're in the toplevel build directory for PAR::Packer,
what is the output of:
$ readelf -d myldr/par
My guess: it's a RUNPATH vs RPATH issue.
Cheers, Roderich
On Mon, Feb 14, 2011 at 4:31 PM, Michael Miller wrote:
> Here's the output from the 'readelf' command:
>
> Dynamic segment at offset 0xf040 contains 20 entries:
> Tag Type Name/Value
> 0x0001 (NEEDED) Shared library:
> [/usr/lib/perl5/5.8/i
On Mon, Feb 14, 2011 at 7:17 PM, Michael Miller wrote:
> LWP will support https URLs if the Crypt::SSLeay module is installed
> AND
> 500 Can't locate object method "new" via package
> "LWP::Protocol::https::Socket"
>
> I guess I'm missing a shared library or something I need to copy over to the
On Mon, Feb 14, 2011 at 10:24 PM, Roderich Schupp
wrote:
> Sorry, there's nothing I can do on the PAR::Packer side. If you know
> the right incantation
> to stop gcc hardwiring library references, patch the above line in
> myldr/Makefile and let me know.
Another idea: if you als
On Tue, Feb 15, 2011 at 9:47 PM, Michael Miller wrote:
> Floating exception - core dumped
>
> So my deployment package to the 1st target box works but the 2nd target (SCO
> 5.0.6) does not.
Well, the packed executable is kinda sensitive to the OS environment,
so I wouldn't expect
it to work on e
On Fri, Feb 18, 2011 at 9:55 PM, Paul Miller wrote:
> Steffen Mon, 15 Oct 2007 23:49:18 -0700:
>> > /usr/bin/make -j3 -j3 -- NOT OK
>> [...]
>>
>> This is probably the culprit of the PAR::Packer failure: You can't make
>> PAR::Packer with parallel (-j3) make. Try installing it without the -j
>>
On Sun, Feb 20, 2011 at 12:48 AM, Paul Miller
wrote:
> It would be most appreciated. I'm quite sure it can be done,
My little rework of the build system can be found at
http://svn.openfoundry.org/par/PAR-Packer/trunk
I've tested on Linux, Windows (Strawberry) and Cygwin, but testers on other
p
On Fri, Feb 25, 2011 at 5:54 AM, Maurice Mengel wrote:
> And get this error message when trying to execute it:
>
> Can't locate loadable object for module XML::LibXSLT in @INC (@INC
> ...
> auto/XML/LibXSLT/LibXSLT.bs and LibXSLT.xs.dll.
There's the first hint: LibXSLT.xs.dll - note the unusual m
On Fri, Feb 25, 2011 at 6:07 PM, Maurice Mengel wrote:
> 1) Corrections: XML::LibXSLT does show up in scandeps.pl output
Nevermind, found the problem and fixed it.
> On Fri, Feb 25, 2011 at 3:35 AM, Roderich Schupp
> wrote:
>> Looking at LibXSLT.pm (line ~26):
>>
>&
On Tue, Mar 1, 2011 at 2:51 AM, Maurice Mengel wrote:
> it works exactly as you say. Now XML::LibXSLT works with pp!
Thanks for testing. I'll commit the fix, will be in the next release of PAR.
Cheers, Roderich
On Tue, Mar 8, 2011 at 5:36 AM, Travis Williams wrote:
> I am using Crypt::Blowfish and DBD::ODBC on win32/12.12.2/Strawberry When I
> use pp the .exe it creates when 2 zero byte files that correlate to the
> dll's that it should have included and that it is calling for that module.
The pp genera
On Tue, Mar 8, 2011 at 1:58 PM, Travis Williams wrote:
> All the DLL's when unziped are the correct size.
Strange. Can you try the following (it's crucial to do it in the order listed):
1. apply the patch below to an unpacked source of PAR
(adds some diagnostic when extracting DLLs)
2. rebui
@Maurice: thanks for the instructions
@Travis:
> Got this output, Test1, Test2 is mine from the script.
...
> IO error: reading header signature : at (eval 25) line 3
> extracted lib/auto/DBD/ODBC/ODBC.dll to
> C:\DOCUME~1\Travis\LOCALS~1\Temp\par-Travis\cache-Cencal\3d2b5e28.dll => 4
The intere
On Wed, Mar 9, 2011 at 3:14 PM, Travis Williams wrote:
> I'm using the -T option to force the cache name so I don't have to guess
> where it is at :) I only started doing that during troubleshooting
OK
> extracted lib/auto/DBD/ODBC/ODBC.dll to
> C:\DOCUME~1\Travis\LOCALS~1\Temp\par-Tr
> vis\cac
On Fri, Mar 11, 2011 at 1:53 AM, Travis Williams wrote:
> This code breaks, remove the flock and everything works great, I'm using the
Uh, it's the flock for sure. Simple test program (no PAR::Packer involved):
use Fcntl ':flock';
use Archive::Zip qw( :ERROR_CODES :CONSTANTS );
# part 1
my $zip
On Sun, Mar 13, 2011 at 2:58 PM, Mark Dootson wrote:
> On the wider point, PAR::Packer builds with the same flags as Perl is
> configured with - so it's unlikely to be something that can be fixed in
> PAR::Packer alone.
Actually that's not 100 percent guaranteed.
PAR::Packer isn't simply an XS m
On Mon, Mar 14, 2011 at 12:04 AM, Philip Kime wrote:
> I am in a good position to test this now as after several days of pain,
> I have VMs of the right versions to try this on.
Philip, your help in testing this is very much appreciated as I have
only a few platforms myself to test this on.
Chee
On Tue, Mar 22, 2011 at 7:34 PM, Travis Williams wrote:
> Is there a way to make pp check if the script it is compiling (converting,
> transforming to a .exe, etc,etc) actually has all the modules required to
> run that script? I have a few different dev enviroments and and a shared
> repository
d.
>>
>> Another question that came up that I am working around, is there a way to
>> change from decompressing into %TEMP% (in win32) to directory I can define?
>>
>> Travis
>>
>> On Tue, Mar 22, 2011 at 1:52 PM, Roderich Schupp
>> wrote:
>>>
Hi Bob,
I'm forwarding this to the par@perl.org mailing list. This is
generally the first address to turn
to with questions and problems about PAR, PAR::Packer, Module::ScanDeps and
related stuff. You can also find it as "perl.par" in Google Groups.
As for your problem: the "prototype mismatch" w
On Thu, Mar 31, 2011 at 4:41 AM, Bob R wrote:
> Thank you all for your efforts on this. Let me start out by saying I got the
> packer running on my machine!
Thanks for testing Mark's modifications.
> no visible difference. I did get one failure on the tests, but it appears to
> be just trying to
On Thu, Mar 31, 2011 at 1:48 AM, Mark Dootson wrote:
> The zip
>
> http://www.wxperl.co.uk/ppamd64_resource.zip
>
> Contains objects that can be unzipped into the current PAR::Packer source in
> the directory myldr. You want the contained win32.coff / win32.obj to
> replace the originals.
Thanks,
On Thu, Apr 14, 2011 at 11:21 PM, Markus Jansen
wrote:
> I have found that pp packs a lot of modules into the final application
> which are definitely superfluous, but I don't have any clue where they get
> referenced.
No, they aren't superfluous in general, only in your context, but
Module::Sc
On Wed, Apr 27, 2011 at 1:41 PM, Sunny wrote:
> PAR Packager machine:
> HOST1:/home/# aptitude show libc6
> Package: libc6
> State: installed
> Version: 2.11.2-10
>
> Target machine:
> HOST2:/home/# aptitude show libc6
> Package: libc6
> Version: 2.3.6.ds1-13etch10
> Section: libs
There's no way
On Mon, May 9, 2011 at 1:49 AM, Peter Buck wrote:
> I handled all the dependencies listed in the Par-Packer installation, and
> downloaded and installed gcc. But am getting an error in the nmake:
> C:\Perl\site\par\PAR-Packer-1.006>nmake
> Microsoft (R) Program Maintenance Utility Version 1.50
On Mon, May 9, 2011 at 9:43 AM, Roderich Schupp
wrote:
> Are you using ActiveState Perl (5.10.1)? Then you'll probably run into
>
> c:\STRAWB~1\c\bin\g++.exe main.o my_par_pl.o win32.coff -s
> -L"P:\_Services\IT
> for_IT\Synergy_Subversion\Support\Active
On Thu, May 19, 2011 at 10:54 PM, Markus Jansen
wrote:
> an "easier way" could mean some means to minimize the startup costs for the
> other Perl scripts -
> as --reuse targets toward the execution of external Perl scripts, we are
> talking here about "internal" scripts,
I can't see the differe
On Mon, May 23, 2011 at 1:34 PM, Mark Dootson wrote:
> $^X -MIPC::Run::Win32Pump -e 1 blah blah
>
> Come to think of it, to make my ugly code work I think you need to use the
> --reuse option to pp - then I assume you get something workable in $^X.
It's even more complicated :(
- $^X is always t
On Mon, May 23, 2011 at 2:49 PM, Mark Dootson wrote:
> The following may be worth a try then, assuming pp passes all the arguments
> and assigning to S^X doesn't break everything else. :-)
Err, no. pp doesn't enter the picture at run time. And when invoking
$ENV{PAR_PROGNAME}
you MUST pass "--par
On Tue, Jun 14, 2011 at 9:23 AM, nikos wrote:
> building an executable with Strawberry Perl is successful but when
> actually running the exe (after we have renamed the c:/strawberry to
> c:/strawberryX so it cannot find the dependencies from the path),
> fails with the following errors :
>
> " Ca
On Wed, Jun 15, 2011 at 11:15 AM, Nikos wrote:
>>pp -o show_inc.exe -e "print qq[INC = \@INC\n]"
>>.\show_inc.exe
>
> It just displays :
> INC = @INC
Sorry, one backslash too many, should have been
pp -o show_inc.exe -e "print qq[INC = @INC\n]"
>>did you build PAR::Packer yourself?
> yes got
On Wed, Jun 15, 2011 at 11:38 AM, Nikos wrote:
>>pp -o show_inc.exe -e "print qq[INC = @INC\n]"
>
> INC =
> E:\DOCUME~1\LOCALU~1\LOCALS~1\Temp\par-LocalUser\cache-24fc4e15c702dfc458f
> 533f99fd8ae8a8261ffb5\inc CODE(0x10cf89c) CODE(0x125fe94)
That looks OK. But the problem occurs probably earlier
On Wed, Jun 15, 2011 at 1:12 PM, Nikos wrote:
> before I run any test, should I 'rollback' any changes I've made (revert
Not necessary as I can reproduce your problem here after a clean
install of the Strawberry 5.12.3.0 MSI + "cpan -i PAR::Packer"
BTW, my Strawberry says (different from yours)
On Tue, Jun 14, 2011 at 8:09 PM, Reini Urban wrote:
> IO is a particular exception and hard to find in the scanner,
> as I know from the compiler.
IO is a red herring :)
It's total irrelevant here because Module::ScanDeps doesn't come
into play at all - the IO and IO::* modules are already needed
On Wed, Jun 15, 2011 at 3:38 PM, Roderich Schupp
wrote:
> Puzzled, Roderich
Not anymore :) In fact loading of XS modules (i.e. the DLLs) has been broken
for _all_ platforms with Perl 5.14.0, because 5.14.0 (actually starting
with 5.13.6) changed XSLoader.pm. This causes the hack used by
On Thu, Jun 16, 2011 at 10:36 AM, Reini Urban wrote:
> BTW: The XSLoader API is a joke, really.
Seconded. If there were a better API (or even better a "legal"
interposer interface)
PAR::Packer wouldn't have to patch the copy of XSLoader.pm that
it packs into every pp-generated executable.
Same g
On Thu, Jun 16, 2011 at 7:14 PM, Nine Fox wrote:
> I need to make use of PP and not just PAR. hence I'm installing a lower
> version of PAR. Is this something that has been encountered earlier?
Please install the latest versions of PAR (1.002) and PAR::Packer
(1.009) from CPAN -
there is absolute
The error you got is most likely due to a PAR::Packer built with one version of
perl and used to pack executables with another perl. In your case probably you
have mixed up the libperl.so (or similar) of the "standard" with the one of
yourl local version. This may happen very easily esp. If you'
On Fri, Jun 17, 2011 at 6:59 AM, Nikos wrote:
> can you shed more light on the internals of why my quick 'hack' worked
> before patching PAR? it was a hack based on observation rather than having
> knowledge of the internals
Dunno. Maybe there's another problem still lurking there. Or your testin
On Tue, Jun 21, 2011 at 7:36 AM, Nikos wrote:
> 3.XSLoader.pm is version 0.15 and does not contain a 'goto retry' reference
That means: it's the "new" version. So what?
Cheers, Roderich
On Tue, Jun 21, 2011 at 12:59 PM, Nikos wrote:
> I mean that the patch not only fixes 5.12 but could be applied to earlier
> versions as well i.e 5.10.1.5 in this case
Thanks for confirmation. The patch actually doesn't care which version
your Perl is, it's the version of XSLoader that you have
On Thu, Jul 21, 2011 at 9:04 PM, Mark Dootson wrote:
> The close(fh) statements in boot.c may cause application to crash if the CRT
> version is 1400 or above for 32 bit or 1500 and above for 64 bit.
What exactly is the problem with close(fh) here? Invalid fh?
Cheers, Roderich
On Fri, Jul 22, 2011 at 9:48 AM, Mark Dootson wrote:
> So, the int / file descriptor we pass to close() is being interpreted as
> invalid.
Got it: the code for the first file written from boot.c does a second
close() on an
already closed file descriptor:
i = my_mkfile( argv[0],
First of all: please don't reply to a post that has absolutely nothing
to do with your problem.
On Fri, Sep 9, 2011 at 10:06 AM, Angelos Karageorgiou wrote:
> Failed to connect to , Can't locate object method "__load_plugins" via
> package "
> MozRepl" at MozRepl.pm line 308.
AFAICT, MozRepl has
On Fri, Sep 9, 2011 at 1:05 PM, Angelos Karageorgiou wrote:
> A biiig question now
>
> how does -x handle program that don't exit ?
pp won't exit either :) Fall back to manually add -M's to the pp command line.
Alternatively apply the following patch to Module::ScanDeps
--- lib/Module/ScanDeps.p
On Sat, Sep 10, 2011 at 3:57 AM, Terrence Brannon wrote:
> if you execute makefile.pl to produce a PAR::Packer version of
> somefile.pl, Some::File fails to find it's own file.
>
> __FILE__ appears to provide a relative path computed at compile time?
> I wonder why the computed path was not made a
On Tue, Sep 20, 2011 at 8:18 AM, Philip Kime wrote:
> This seems to make some Module::ScanDeps tests fail as they expect a
> dynamic Cwd (they look for Cwd$dlext). It seems to work when force
> installed but I'm a bit concerned about what happens when M::SD is
> used by PAR::Packer to pack someth
On Fri, Oct 14, 2011 at 8:42 PM, Buck, Peter wrote:
> In Windows 7, after expanding PAR 1.002, I ran perl Makefile.pl and then
> nmake. Nmake failed with a message I can't interpret. Can someone help?
> Thanks - Peter
> C:\Users\buckpete\Downloads\PAR\PAR\PAR-1.002>nmake
> syntax error at -e
On Tue, Oct 25, 2011 at 11:33 PM, Marc Green wrote:
> I am using pp to create an executable from my perl script and am running
> into problems. My script uses 5.14.0, and I can run it successfully by using
> that version of perl via perlbrew. My system perl version is 5.10.1.
Sorry, dunno anythin
On Wed, Oct 26, 2011 at 10:43 AM, Roderich Schupp
wrote:
> Obviously you must install PAR::Packer in all perlbrew managed versions
> and also use the corresponding pp.
On a more general note: If you have multiple versions of Perl installed
on a machine, you must be very careful that PAR::
2011/11/17 Jarek Lubczyński :
> And the point is: in the first phase of executing PAR loader looks for temp
> directory, if it doesn't exist, loader extracts archive into it and then
> runs the main script. But if something break the extraction (the user will
> press Ctrl-C for example), the archiv
On Tue, Nov 22, 2011 at 7:07 PM, wrote:
> I would like to use the
> toolkit to create a .par file with all modules my current script uses and
> distribute that among my team to maintain strict module version control and
> reduce perl distribution variation (i.e. several people on the team use
> A
On Mon, Dec 5, 2011 at 3:23 AM, Gary Yang wrote:
> I use the command, "pp -f Crypto -F Crypto -M Filter::Crypto::Decrypt -o
> testPP testPP.pl" to encrypt the script.
First of all, encrypting the script is a red herring, it has nothing
to do with the problem.
> But, I got 'Unknown PerlIO layer
201 - 300 of 1084 matches
Mail list logo
