On Fri, 2003-08-08 at 12:19, [EMAIL PROTECTED] wrote:
On Fri, Aug 08, 2003 at 10:55:20AM +0200, Roderich Schupp wrote:
after installing the latest and greatest
(Module::ScanDeps 0.22, PAR-Dist 0.04, PAR 0.73)
I get the following error with everything that pulls
in (directly or indirectly
On Thu, 2003-08-07 at 20:44, [EMAIL PROTECTED] wrote:
The lib/auto/Tk subdirectory on Linux is 14M in size, compared with 1.5M
on OS X and 1.2M on Win32.
The big culprit on Linux appears to be lib/auto/Tk/Tk.so, which is 7MB.
Probably your libraries haven't been stripped,
my numbers (Debian
On Tue, 2003-08-12 at 18:17, [EMAIL PROTECTED] wrote:
That sounds like a sane idea. Can you test the patch below a bit,
and let me know if there's anything still missing?
Alternatively, a snapshot that contains the same patch is available at:
On Thu, 2003-08-14 at 19:34, [EMAIL PROTECTED] wrote:
I'm trying to understand why scanning a 1000 line script
(albeit one using Tk and some other modules) takes 45 seconds
on an otherwise speedy Sun E4500.
I wonder too. Can you do a dprofpp on it?
Oops, I tried Perl 5.6.1 on Solaris,
On Fri, 2003-10-17 at 00:28, [EMAIL PROTECTED] wrote:
Hi,
I use perl 5.8.0 and par 0.75. We have a network installation of
perl in /tools/sunos/perl58, where I built an executable. I am having
trouble running this executable built on a machine in a different network.
This machine has
On Fri, 2003-10-17 at 15:31, [EMAIL PROTECTED] wrote:
Roderich,
I get the same error even after adding libz.so. The script I am
converting is an interactive script. When I run it on the machine where I
built it and interrupt it while it's runnig, I can see in the
/tmp/par_privtmp/
On Mon, 2003-10-20 at 22:03, [EMAIL PROTECTED] wrote:
On Mon, Oct 20, 2003 at 03:13:22PM +0200, Markus Jansen wrote:
On Fri, 2003-10-17 at 15:31, [EMAIL PROTECTED] wrote:
Actually, executing a PAR-packed exe works like this -
Autrijus correct me if I got this wrong:
(1) exe creates a
On Wed, 2003-11-26 at 16:45, [EMAIL PROTECTED] wrote:
FTP.pm . When I try to run this executable on a different machine, which do
not have perl installed, the executable cannot locate the Socket.so.
I see the same behaviour with PAR 0.75 on Solaris,
but PAR 0.76 looks OK (Socket.so doesn't show
Hi,
the recently (27 Nov 2003) released Archive::Zip 1.09 doesn't get
quite get along with PAR 0.76.
On WindowsXP, Perl 5.8.1, I get:
C:\temp\cpan\build\PAR-0.76pp -o hello.exe -e print q[hello]
C:\temp\cpan\build\PAR-0.76hello.exe
format error: bad signature: 0x00905a4d at offset 0 in file
On Wed, 2003-12-10 at 13:01, [EMAIL PROTECTED] wrote:
the recently (27 Nov 2003) released Archive::Zip 1.09 doesn't get
quite get along with PAR 0.76.
Forgot to mention: you have to rebuild PAR _after_ installing
Archive::Zip 1.09 to reproduce the problem.
Cheers, Roderich
On Thu, 2003-11-20 at 15:44, [EMAIL PROTECTED] wrote:
I'm packing a Perl-Tk application into an executable.
This works fine when using the stable version of Tk (800.024).
But when I switch to the latest beta (804.25_beta6),
the app starts and behaves OK, except that all characters
are
On Wed, 2003-12-17 at 17:18, [EMAIL PROTECTED] wrote:
I sent the response below to Autrijus yesterday, but forgot to CC the
par list. I'd be very grateful if someone else using PAR under perl
5.8.1 or 5.8.2 could try the simple test that's described below to
verify the existence of this
Hi,
there's a problem with pp -M It shows when you
compare the result of the following commands
$ pp -o use.exe -p use $MOD; print q[OK]
$ pp -o minusm.exe -M $MOD -e print q[OK]
for some MOD (e.g. MOD=Tie::IxHash,Encode::Unicode,DBI)
Comparing the zip's contents (as shown by unzip -l
, Roderich
--
sw-engineering production environment at BMW group
--
roderich schupp (argumentum gmbh)
[EMAIL PROTECTED]
+49 (0)89 382-34944
http://www3.muc/bereiche
- Original Message -
From: Roderich Schupp [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 07, 2004 11:06 AM
Subject: Problems with pp -c ...
the following program
use Storable;
print hello, world\n;
has problems when packed with
$ pp -n -c -o hello.exe hello.pl
Running
On 9/10/06, Steffen Mueller [EMAIL PROTECTED] wrote:
IvorW schrieb:
/usr/bin/ld: cannot find -lperl
collect2: ld returned 1 exit status
Do you need to install the libperl-dev package, i.e. the perl headers
for this? I might be totally off, though. (But I don't think I am.)
Judging from your
Success! Thank you again. I wonder if PAR could be packaged up for Debian.
It already is (though only for Debian unstable), the package is called
libpar-perl.
Cheers, Roderich
As most of you probably know, various modules (some of them using XS)
are built into parl(.exe), the PAR binary loader which is prepended to
any binary executables produced by pp, at build time.
I've just conducted a litle experiment and now I'm not so sure that
this description of the workings
Hi Steffen,
Roderich, you showed me a proof-of-concept reimplementation using self
extracting libzip. Would you think you could modify the parl building
process to use libzip instead of the corresponding Perl XS modules? Or
I certainly would like to expand on my proof-of-concept, at least to
On 9/20/06, Chris Dolan [EMAIL PROTECTED] wrote:
On Sep 18, 2006, at 5:09 AM, Steffen Mueller wrote:
a) link in C libzip to do the extraction. That way, parl wouldn't
need any Perl at all just for the extraction of the .par
Just a small note: this would have the positive side effect of making
On 10/18/06, rahed [EMAIL PROTECTED] wrote:
I packed with pp command this way:
pp -o foo.exe foo2.pl -l /many/libraries/here
When executing foo.exe the executable ends up with 'main.pl: Can't open
perl script foo: No such file or directory at script/main.pl line 5'.
If I change foo2.pl to
On 10/25/06, Steffen Mueller [EMAIL PROTECTED] wrote:
open ( $fh, , \$data ) or die can't open string fh: $!;
[...]
That's the culprit!
I explained this in detail in
https://rt.cpan.org/Public/Bug/Display.html?id=11108
I concur that Module::ScanDeps can't statically detect whether a given
On 10/25/06, Steffen Mueller [EMAIL PROTECTED] wrote:
At first, I thought modules passed to pp via -M just weren't scanned at
all, but they are! (pp -M Math::Symbolic -e 'print Hello\n;' packages
Parse::RecDescent alright.)
Yeah, modules are scanned either way, but the %Preload magic of M::SD
On 10/31/06, Daniel McBrearty [EMAIL PROTECTED] wrote:
sure. where can I get a more recent one for win32 though? I'd prefer
not to have to build it, if possible ...?
I think your problem is that the perl environment that got
somehow captured (in parl.exe and parldyn.exe) when your PAR package
On 10/31/06, Daniel McBrearty [EMAIL PROTECTED] wrote:
I have visual studio. So if I compile with that, it should be OK with
my pre-built perl, even though that may have been built with a
different compiler and so on? (I only usually build perl c from
AFAIK ActiveState builds with Visual
On 11/5/06, Steffen Mueller [EMAIL PROTECTED] wrote:
My money is on option three.
Blech, mine too.
The thought occurred to me that we might solve this problem by appending
the required modules to a stripped-down copy of parl.exe just before
I just did a little experiment (on Linux, but
On 11/6/06, Peter Gordon [EMAIL PROTECTED] wrote:
has Scalar/Util.pm (and also Scalar/Util.so or Scalar/Util.dll) been
packaged,
run unzip -l your_executable to check
# unzip -l app_diag.exe | grep Util
56: 2050 11-06-06 08:21 lib/List/Util.pm
61: 3572 11-06-06 08:21
On 11/6/06, Philippe Schaffnit [EMAIL PROTECTED] wrote:
I think it's a simple Makefile problem:
static.c #includes mktmpdir.c, my_perl.c, and my_par.c but static.o doesn't
depend on them (it only implicitly depends on static.c). static depends on
my_par.c, but that doesn't mean that static.o must
On 11/6/06, Roderich Schupp [EMAIL PROTECTED] wrote:
If this works, change myldr/Makefile.PL accordingly.
Patch attached (against PAR-0.957).
Cheers, Roderich
--- myldr/Makefile.PL.orig 2006-11-06 19:26:09.0 +0100
+++ myldr/Makefile.PL 2006-11-06 19:32:45.0 +0100
@@ -224,7
On 11/7/06, Peter Gordon [EMAIL PROTECTED] wrote:
At this point either I have made a mistake and/or am thoroughly
confused.
No, it's what I suspected. Your build of PAR has been done against some
older version of perl (or at least of Scalar::Util) - that's the stuff
extracted with
my script.
On 11/16/06, Philip Gwyn [EMAIL PROTECTED] wrote:
On 15-Nov-2006 Roderich Schupp wrote:
OK, given your experiment with LD_LIBRARY_PATH and LD_PRELOAD:
what does readelf -d (or the Dynamic section in the output of objdump
-ax
if you don't have readelf) say when run on the executable
On 12/19/06, Philip Gwyn [EMAIL PROTECTED] wrote:
But I gave up on that route, and tried to find out why LD_LIBRARY_PATH was
failing. Groveling through strace output, which I should have done back then.
The problem was that I was using the --tempcache param to pp (I submitted a
patch for this
pp -M XML::LibXML::SAX::Parser ...
Thx for this detailled answer, but using -M flag like this don't work with the
pp I use (version 0.973)
= Cannot open : No such file or directory at
/path/perl-5.8.8/lib/site_perl/5.8.8/Module/ScanDeps.pm line 477.
That simply means you don't have
On 3/13/07, Dwight Oakey [EMAIL PROTECTED] wrote:
When I do try to run the executable on another computer, I receive the
following error:
C:\a.exe
Can't locate PAR/Heavy.pm in @INC (@INC contains: CODE(0x7e5544) .) at –e
line 307.
@INC looks fishy, here's what I get (same
On 3/14/07, Dwight Oakey [EMAIL PROTECTED] wrote:
C:\Documents and Settings\doakey\My Documents\Perlpp -o hello.exe -e print qq[
INC = @INC\n];
C:\Documents and Settings\doakey\My Documents\Perlhello.exe
INC = C:\Temp\par-doakey\cache-48d2962a05347ff8390007247747db177006800a\inc CODE
(0xe38e88)
On 3/16/07, Bob Hunter [EMAIL PROTECTED] wrote:
Using pp -M Text::Abbrev or -M IO::LockedFile::Flock
does not help. The only way around is to call the
required child module (Text::Abbrev,...) from the main
and remove the call from the parent module
(DBI::Format, ...).
Most likely a problem
On 3/17/07, Bob Hunter [EMAIL PROTECTED] wrote:
scandeps.pl -B shows the modules to me too, but the
original problem is still pending.
OK, I should have read your original post more thoroughly:
I can explain the missing IO::LockedFile::Flock - it isn't reportted
by Module::ScanDeps, because it
On 4/11/07, Jason Forkey [EMAIL PROTECTED] wrote:
Am I trying to do something that won't work? I would have expected to have a
problem if I tried to build an executable, but I would think that a standalone
I just tried your example and - contrary to my reading of the documentation
for pp - it
A PAR file is actually a zip file and is handled by Archive::Zip.
AFAICT, Archive::Zip always treats zip member names in a case sensitive manner.
Cheers, Roderich
On 5/19/07, m.nooning [EMAIL PROTECTED] wrote:
There are two things that come into play here.
10 seconds for the first time the exe is invoked is actually reasonable,
depending on your machine. Compare that with the first time you call
Well, I'd rather say it's expected with the current
On 5/21/07, howard chen [EMAIL PROTECTED] wrote:
In fact, will it be possible to tell pp not to compress? since
sometimes we just want an executable, size does not matter...
AFAIK no. The problem is not the compression per se, it's
the wicked way PAR does the decompression - try a simple unzip
On 6/4/07, Jon Polacheck [EMAIL PROTECTED] wrote:
Thanks for the feedback. Here is the output;
(1) What's your version of Module::ScanDeps?
0.74
Current, OK
'POE'= '0.37',
Looking at http://search.cpan.org/~rcaputo/POE/ the other POE::*
entries look reasonable,
Hi,
I just tried to pp the first example from
http://poe.perl.org/?POE_Cookbook/Tk_Interfaces
and got a similar result to yours (complaints about missing POE::Session and
PO::Loop::Select) on Linux, so it's not Windows specific.
Here's a patch for Module::ScanDeps 0.74
- fix typo POE - POE.pm
-
On 6/24/07, deadpickle [EMAIL PROTECTED] wrote:
I got it to work.
When I go to run the exe program I get th error:
C:\Documents and Settings\deadpickle\Desktop\GRRUVIpp -o GWC.exe
GWC.pl
C:\Documents and Settings\deadpickle\Desktop\GRRUVIGWC.exe
Can't locate attributes.pm in @INC (@INC
On 6/25/07, Steffen Mueller [EMAIL PROTECTED] wrote:
Eric Wilhelm schrieb:
Perhaps a --bloat flag? At least a --nobloat option please.
Perhaps a --bloat flag? At least a --nobloat option please.
Well, my attributes.pm here is 2212 bytes, I wouldn't call that bloat :)
In fact, you always
On 8/13/07, Neta Ben-Porat [EMAIL PROTECTED] wrote:
When I tried 'pp -B -o Test Test.pl', an executable was created but when
I've tried running it elsewhere I got the message: 'XMLin() requires
either XML::SAX or XML::Parser at script/CorrectDNIXML.pl line 80'
You're obviously use'ing
On 10/1/07, Babul [EMAIL PROTECTED] wrote:
I am using ActiveState perl ver 5.6.1.638.
I have downloaded PAR-0.85_01.tar.gz., unzipped in a folder and then
Please use the current version of PAR and PAR::Packer
(PAR has recently been split up into these) - 0.976 is currently on CPAN.
No
On 10/25/07, Ch Lamprecht [EMAIL PROTECTED] wrote:
packing a Tk applicatin with pp, I found that although Tk::FBox is
correctly detected and included, Tk::Bitmap is not.
Tk::FBox depends on Tk::Bitmap, maybe this should be added to the
Tk::FBox %preload entry (line 381 of
On 10/25/07, Roderich Schupp [EMAIL PROTECTED] wrote:
Maybe... though I don't know why Module::ScanDeps doesn't pick up
Tk::Bitmap, the short example below (that's just the context of the single
The problem is line 570 of Module/ScanDeps.pm:
foreach my $file (@{$files}) {
my $key
On 11/6/07, 0xbeef [EMAIL PROTECTED] wrote:
IO error: Can't open file /tmp/par-root/
cache-880362d2eb1c66eb77f72ddaa4298178/libgd.a for write : Cannot open
or remove a file containing a running program.
This happens since the shared library is still loaded in memory by the
O/S when the PAR
On Nov 27, 2007 11:05 PM, Scott Stanton [EMAIL PROTECTED] wrote:
Steffen Mueller wrote:
That's actually a good idea: Avoiding dll file name clashes using a
directory for each external (non-perl-module) dll. Currently, we
extract
the external dlls under their original name, IIRC.
On Nov 28, 2007 5:42 PM, Scott Stanton [EMAIL PROTECTED] wrote:
The intent isn't to avoid name clashes within a single application, it's
to avoid version clashes across applications with a shared cache
directory. Instead of creating a separate cache-sum directory for
every application, you
On Nov 28, 2007 6:39 PM, Scott Stanton [EMAIL PROTECTED] wrote:
I'm trying to ship a self contained application to our customers. We
are not allowed to dictate to the customer what versions of perl and
installed packages they may have on their machine outside of our
installation directory.
On Jan 8, 2008 8:09 PM, Glenn Linderman [EMAIL PROTECTED] wrote:
I'm not sure of where the implementation is, or what constraints it is
under, but would it be possible to provide this option based on an
environment variable, instead of a hacked build/package time option?
Pass the value of the
On Jan 8, 2008 9:59 PM, Glenn Linderman [EMAIL PROTECTED] wrote:
Ah, so the new pp option ( --prepare_for_debugging equivalent to -M
perl5db.pl) would still be required to make a debuggable package, by
including the debugger. That makes sense.
And then the debuggable package would have a
On Jan 9, 2008 11:49 AM, Steffen Mueller [EMAIL PROTECTED] wrote:
Roderich Schupp wrote:
So I'm all for making it a run-time option, environment variable preferred:
PAR_DEBUG is already taken, what about PAR_PERL_DEBUG or
PAR_DEBUG_PERL?
perhaps I'm not getting something, so please bear
On Jan 9, 2008 11:42 AM, Markus Jansen [EMAIL PROTECTED] wrote:
I am just curious - has anybody looked into the Enbugger module?
I did :)
This is a really nice module and you can certainly use it with PAR, but...
(1) You still must take care of packing the actual debug modules yourself
(2) It
On Jan 9, 2008 11:18 AM, Steffen Mueller [EMAIL PROTECTED] wrote:
Roderich Schupp wrote:
i.e. encode_append.pl refuses to overwrite the obsolete __DATA__ sections
from
the last build. Patch attached.
Your patch looks good to me, but I can neither test or apply it
currently. Feel free
On Wed, Feb 13, 2008 at 9:10 PM, Rinkes, Dan [EMAIL PROTECTED] wrote:
I have a script that uses a module that uses Inline java. I built the
executable with the command pp -M Findbin -M Inline -o foo.exe foo.pl.
However, when I run the .exe with the same parameters that I have
successfully
On Thu, Feb 14, 2008 at 2:33 AM, Kang [EMAIL PROTECTED] wrote:
I'm using Strawberry Perl 5.10 for win32.
but packed binary with pp on it raises can't find perl510.dll error.
There is no such problem in Strawberry Perl 5.8.
Please give some more information what you did and what doesn't
On Fri, Feb 15, 2008 at 12:55 AM, Kang [EMAIL PROTECTED] wrote:
After making simple script, and packing with 'pp -o script.exe script.pl'
command.
Execute packed binary in the other computer which don't have perl or after
removing environment variable installed by strawberry perl
if you
On Feb 18, 2008 6:39 AM, Henry Wu [EMAIL PROTECTED] wrote:
I am building perl/tk application with some icon images. I am trying to
package all the referenced images to the produced exe too.
I know I can add extra image file to the produced exe using --addfile
option, but how do I
On Wed, Mar 26, 2008 at 3:15 AM, Brad Bowman [EMAIL PROTECTED] wrote:
I've encountered another instance where odd pod (maybe malformed)
is incorrectly stripped. In this case, a =head1 is left behind
causing the code following to be commented out (Can't find method
init via ...)
Steffen
On Tue, Apr 1, 2008 at 11:43 PM, Mock, George [EMAIL PROTECTED] wrote:
The executables work fine on Windows and Linux machines. Except one
customer of mine, who is running a Linux executable, see this error:
Can't locate object method new via package XML::Parser at
XML/Simple.pm
On Mon, Apr 14, 2008 at 11:43 PM, [EMAIL PROTECTED] wrote:
The executable was built with perl 5.8.6.
There might have been some changes between 5.8.6 and 5.10.0 to DynaLoader,
but I doubt that this would influence library search order for libraries
thar are indirectly loaded by the system
On Wed, May 14, 2008 at 3:39 PM, Dave Howorth
[EMAIL PROTECTED] wrote:
Being lazy, I thought I'd try a different approach first. Since it seems
that the initial problem is the dynamic linking of the embedded perl, I
thought I'd try building a file without perl, and see if the one on the
On Tue, May 27, 2008 at 11:09 PM, Henry Wu [EMAIL PROTECTED] wrote:
I packaged an executable abc.exe from perl script using pp. Worked
fine for most of users, But some users have existing old perl
installation and have environmental variable PERL5LIB set. When these
users run the abc.exe,
On Fri, May 30, 2008 at 3:46 AM, Paul Miller [EMAIL PROTECTED] wrote:
The hash re-naming of packages is also the only reason PAR can't
*unpack* Gtk2-perl applications -- it packs them correctly.
Can you elaborate on this? AFAIK the hash-renamed packages are only
those modules that are minimally
On Fri, May 30, 2008 at 1:26 PM, Roderich Schupp
[EMAIL PROTECTED] wrote:
AFAIK the hash-renamed packages are only
those modules that are minimally needed to use PAR.pm.
Sorry, spoke to soon. All shared (glue) libraries (e.g.
LibXML.so for XML::LibXML) are also hash-renamed,
probably under
On Fri, May 30, 2008 at 2:46 PM, Paul Miller [EMAIL PROTECTED] wrote:
On Fri, May 30, 2008 at 02:15:51PM +0200, Roderich Schupp wrote:
Do the Gtk2 modules use some non-standard procedure
to dynamically load their shared glue libraries
that foils PAR's intercept?
No, standard. I think
On Tue, Aug 12, 2008 at 3:40 PM, Wes Hardaker
[EMAIL PROTECTED] wrote:
On a F9 machine when I run this:
pp -o test -e 'print hello world\n;'
And then take the results to an F6 machine and run it I get this:
./test: symbol lookup error:
On Tue, Aug 12, 2008 at 5:43 PM, Wes Hardaker
[EMAIL PROTECTED] wrote:
FYI, I tried moving the above Zlib.so aside and it worked after that...
so it is definitely loading the wrong Zlib package first. My guess is
that the unzip process isn't setting the right path and @INC is changing
later
On Tue, Aug 12, 2008 at 7:16 PM, Wes Hardaker
[EMAIL PROTECTED] wrote:
way, right now it's loading the system shared object when it should be
loading the internal one.
Yeah, back at home I can reproduce your problem on Debian, too
(PAR 0.980, PAR::Packer 0.982). I ran your hello, world
On Tue, Aug 12, 2008 at 11:55 PM, Wes Hardaker
[EMAIL PROTECTED] wrote:
Right, but it *does* still still find it in the non-standard path if the
standard one doesn't exist which at least makes me think the search path
actually contains the new extraction (somehow; again I'm clueless on the
On Fri, Aug 15, 2008 at 11:36 PM, Bob Davis [EMAIL PROTECTED] wrote:
It seems that if PERL5LIB is set then the exe generated from pp doesnt work
on the target client. This happens in particular when oracle is installed on
the client. This was discussed in another thread and it was suggested
On Mon, Aug 25, 2008 at 9:02 PM, Gabor Szabo [EMAIL PROTECTED] wrote:
The executable created by this code runs on some Linux systems
but someone reported this:
./padre_0.05_linux_t1
./padre_0.05_linux_t1: /lib/tls/libc.so.6: version `GLIBC_2.4' not
found (required by ./padre_0.05_linux_t1)
On Thu, Aug 28, 2008 at 4:22 PM, Gabor Szabo [EMAIL PROTECTED] wrote:
At start-up I get a warning pop-up with the following text:
libwx_gtk2_html-2.8.so.0: cannot open shared object file: No such file
or directory
If I click on the details I get this:
libwx_gtk2_stc-2.8.so: cannot open
On Fri, Aug 29, 2008 at 10:23 AM, Gabor Szabo [EMAIL PROTECTED] wrote:
pp -o padre -I lib script/padre -M Data::Dum
Cannot open : No such file or directory at
/home/gabor/perl5lib/lib/Module/ScanDeps.pm line 573.
I gave a none-existent module on purpose.
Module::ScanDeps should at least
On Wed, Oct 1, 2008 at 8:55 AM, Steffen Mueller
[EMAIL PROTECTED] wrote:
#!/usr/bin/perl -w -I/home/valdar/perl/include/
That's the culprit. The command line options get lost. This is currently
This #! line is also non-portable: most operating systems will only
recognize at most one option to
On Wed, Oct 1, 2008 at 10:20 AM, Mark Dootson [EMAIL PROTECTED] wrote:
Isn't the underlying problem, in this particular case, Perl 5.10 regex
engine dependency on Tie/Hash/NamedCapture.pm ?
Ouch, missed that one. So Tie/Hash/NamedCapture.pm is something like
Errno.pm, i.e. require'd by the
My guess would be that 'use English' is a probable culprit - but I've never
bothered to find out what the specific things are that cause
Tie::Hash::NamedCapture to load.
Probably referencing %- or %+ does it (they are actually tied hashes of
the above kind). use English references them by
On Wed, Nov 19, 2008 at 8:07 PM, Veera, Bharath Kumar
[EMAIL PROTECTED] wrote:
I've built the perl binary with pp on HP UX 11.23 while running the same on
another test machine, the build fails with the following error:
I strongly agree with the first solution as the binary should ideally not
On Fri, Nov 21, 2008 at 4:45 PM, Veera, Bharath Kumar
[EMAIL PROTECTED] wrote:
bash-2.05b$ ./showinc
INC = CODE(0x4075a860) CODE(0x4075a9d4)
Looks a little suspicious, I get something like
INC = /tmp/par-roderich/cache-719a7d4b038d190b2a8ec4dffa4817062a864212/inc
CODE(0xf2d1e0) CODE(0xf36518)
On Mon, Dec 22, 2008 at 7:35 PM, Alan Dickey alan.dic...@gmail.com wrote:
$ pp -e 'use English; print Hello, world!\n;' -o hello
$ ./hello
Can't locate Tie/Hash/NamedCapture.pm in @INC (@INC contains:
CODE(0x996ffe0)
This has come up before:
On Tue, Dec 23, 2008 at 3:56 PM, Steffen Mueller
wyp3rl...@sneakemail.com wrote:
But I don't have a solution to my problem with i18n and Curses::UI. Any
idea about what Module::ScanDeps isn't finding, if that is indeed the
culprit?
Hmm. Curses::UI is an oddball.
That's putting it modestly.
On Fri, Dec 26, 2008 at 5:12 PM, Roderich Schupp
roderich.sch...@googlemail.com wrote:
Actually, i18n.pm seems to be real culprit: If I switch the order of the
above uses, hello2 runs fine. Same if I replace Term::ReadKey
with another module that has a shared glue library (and isn't one
On Wed, Jan 7, 2009 at 8:47 AM, Robert Fishel bobfis...@gmail.com wrote:
Hey all, just signed up for the mailing list and I'm pulling my hair out
over here. I've downloaded the latest tar.gz file (I have activestate perl)
of par. I unzipped it to a folder. did nmake clean did perl makefile.pl
On Mon, Jan 19, 2009 at 4:12 PM, Deen Kotturi deen_kott...@yahoo.com wrote:
r...@dkotturi-pc-t43:/home/deen# pp -o test.exe test.pl
The program 'pp' is currently not installed. You can install it by typing:
apt-get install libpar-packer-perl
bash: pp: command not found
I checked if PAR is
On Mon, Feb 2, 2009 at 7:08 AM, Octavian Rasnita orasn...@gmail.com wrote:
pp doesn't compile. It creates a package with more files, including the clear
source code of your program.
Correct.
Thomas George wrote:
... is it possible to decompile or display code that is compiled using pp..?
On Mon, Feb 2, 2009 at 6:17 PM, Thomas George thomas.w.geo...@gmail.com wrote:
Wait .. I missed the point of what you were saying .. However, unzip doesn't
seem to know how to unzip an executible created with pp.
Don't get fooled by WIMPy programs or programs insisting on certain
filename
On Thu, Feb 19, 2009 at 4:44 PM, Veera, Bharath Kumar
bharath-kumar.ve...@hp.com wrote:
Executable built with 'pp' doesn't on some target machines with errors as
shown below. I just built an pp executable for printing @INC
bash-2.05b$ pp -o showinc -e 'print INC = @INC\n'
On trying to run
On Thu, Mar 19, 2009 at 8:30 AM, Richard Thomas rich_d_tho...@yahoo.com wrote:
When I try to make an exe of a pl script, I get a pop up window with the
following:
OK, try invoking parl.exe or parldyn.exe (probably in
c:\Perl\site\bin) in a command window.
Does this provoke the same error:
On Sun, Mar 22, 2009 at 1:47 PM, Viswanathan Ramachandran
vis...@gmail.com wrote:
Please check this node.
http://www.perlmonks.org/?node_id=751634
Steffen (tsee on perlmonks) already summed it up nicely -
he _is_ the PAR::Packer maintainer.
Cheers, Roderich
Hi,
after private communication with Richard we were able to determine the reason
why pp failed on this machine:
- the machine runs Perl 5.8.9
- the PAR::Packer PPM that he installed from the trouchelle PPM repository was
built against Perl 5.8.8
This combination can't work - for a rather
On Mon, Mar 30, 2009 at 8:49 AM, Octavian Rasnita orasn...@gmail.com wrote:
Do you know if there is a PAR distribution built with Perl 5.10.0?
http://trouchelle.com/ppm10
has PAR::Packer 0.991 frp perl 5.10.0
I remember that I tried to create a PAR distribution of a Catalyst
application and
On Mon, Mar 30, 2009 at 7:41 PM, Viswanathan Ramachandran
vis...@gmail.com wrote:
I still see the error The procedure entry point Perl_hv_common_key_len
could not be located in the dynamic link library perl58.dll.
This is perl, v5.8.9 built for MSWin32-x86-multi-thread (with 9 registered
2009/4/7 Octavian Rasnita orasn...@gmail.com:
I have tried to run a .par archive made under Linux to run under Windows.
Shouldn't this be possible?
In general, this should NOT be possible.
It may work if the archive contains pure Perl modules only
(i.e. in the absence of any *.so or *.dll files
On Mon, Apr 13, 2009 at 3:33 PM, Memo Garcia memo.garcia...@gmail.com wrote:
But Steffen is also correct when he said that it's strange that it's
failing during linking. Could that missing file be checked previously?
In theory :) But there's not enough information in Perl's
2009/4/20 Octavian Râşniţă orasn...@gmail.com:
I've created a .par archive with a Catalyst app under Windows XP Pro with
Perl 5.10.0 but I can't run a program from that archive because it gives an
error.
I think PAR might not use a certain module which is needed...
Can't locate mro.pm in
2009/4/20 Octavian Râşniţă orasn...@gmail.com:
Thank you. This way it works (even though not well), however I don't think I
should add that line, because I tried to run the perl script from the PAR
archive on the same machine it was created, immediately after creating it,
in the same location
1 - 100 of 875 matches
Mail list logo
