Bug #95417 for PAR-Packer: Perl pp error: Seeking some info

Tue May 06 16:51:45 2014 angan.das [...] intel.com - Ticket created

CC:	"bug-par [...] rt.cpan.org" <bug-par [...] rt.cpan.org>
Subject:	Perl pp error: Seeking some info
Date:	Tue, 6 May 2014 20:50:55 +0000
To:	"autrijus [...] autrijus.org" <autrijus [...] autrijus.org>
From:	"Das, Angan" <angan.das [...] intel.com>

Hi Autrijus, We are trying to use "pp" to compile a Perl-based software developed in-house here at Intel. I have tried perlcc earlier but not with much success. The requirement it might have packages which might call other packages. But once compiled into a binary, it should be truly stand-alone: i.e., able to run from any 64-bit Unix terminal, without assuming any dependencies on Perl whatsoever. What I did is the plain vanilla way: $ pp -o <output>.exe <myfile.pl> When I try the '-help' on the executable on another terminal, I get: $ <output>.exe --help Attempt to reload Scalar/Util.pm aborted. Compilation failed in require at /usr/intel/pkgs/perl/5.14.1/lib64/5.14.1/Compress/Zlib.pm line 8. BEGIN failed--compilation aborted at /usr/intel/pkgs/perl/5.14.1/lib64/5.14.1/Compress/Zlib.pm line 8. Compilation failed in require at -e line 358. It seems I might be missing something. I tried compiling with the few options (-B, -M, etc.) mentioned on the website but not with much success. Could you please help asap? Thanks, Angan

Download image001.gif
image/gif 92b

Wed May 07 03:57:08 2014 RSCHUPP [...] cpan.org - Queue changed from PAR to PAR-Packer

Wed May 07 04:23:39 2014 RSCHUPP [...] cpan.org - Correspondence added

On 2014-05-06 16:51:45, angan.das@intel.com wrote: Show quoted text

> The requirement it might have packages which might call other > packages. But once compiled into a binary, it should be truly stand- > alone: i.e., able to run from any 64-bit Unix terminal, without > assuming any dependencies on Perl whatsoever.

Hi Angan, PAR::Packer should fulfill that requirement :) There's little information in your report to diagnose the problem. Please answer the questions below: - which operating system - which version of Perl: please provide the output of "perl -v" and "perl -V" - where did you get PAR::Packer from: - did you build it yourself (using "cpan" or similar)? - if yes, did you run the test suite and did it pass? - does the problem happen with a trivial script, e.g. $ pp -o hello.exe -e 'print "hello, world\n"' $ ./hello.exe - if not, please provide a minimal example BTW, it's not necessary to explicitly CC any maintainers of the module - they are subscribed to rt.cpan.org anyway. Cheers, Roderich

Wed May 07 04:23:40 2014 The RT System itself - Status changed from 'new' to 'open'

Wed May 07 08:21:31 2014 angan.das [...] intel.com - Correspondence added

Subject:	RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Date:	Wed, 7 May 2014 12:21:20 +0000
To:	"bug-PAR-Packer [...] rt.cpan.org" <bug-PAR-Packer [...] rt.cpan.org>
From:	"Das, Angan" <angan.das [...] intel.com>

Roderich, Thanks for the prompt response. Given below are my inline answers: Show quoted text

-----Original Message----- From: Roderich Schupp via RT [mailto:bug-PAR-Packer@rt.cpan.org] Sent: Wednesday, May 07, 2014 1:24 AM To: Das, Angan Subject: [rt.cpan.org #95417] Perl pp error: Seeking some info <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 > On 2014-05-06 16:51:45, angan.das@intel.com<mailto:angan.das@intel.com> wrote:

> The requirement it might have packages which might call other > packages. But once compiled into a binary, it should be truly stand- > alone: i.e., able to run from any 64-bit Unix terminal, without > assuming any dependencies on Perl whatsoever.

Hi Angan, PAR::Packer should fulfill that requirement :) There's little information in your report to diagnose the problem. Please answer the questions below: - which operating system Suse on SLES10 and SLES11 machines - which version of Perl: please provide the output of "perl -v" and "perl -V" /usr/bin/perl -v This is perl, v5.8.8 built for x86_64-linux-thread-multi - where did you get PAR::Packer from: - did you build it yourself (using "cpan" or similar)? - if yes, did you run the test suite and did it pass? I tried to build it myself but then noticed its already installed in our environment by the env-team. And so what it implies is its already installed property and tested. /usr/intel/pkgs/perl/5.14.1/bin/pp - does the problem happen with a trivial script, e.g. $ pp -o hello.exe -e 'print "hello, world\n"' $ ./hello.exe Yes and no both. I tried running it on a different setup (basically some shell variables set) and it ran fine. I tried running it on a fresh xterm and it ran fine. However, its failing in some particular xterm in some particular setup. I am sure it would be a setup related problem. But I want to rootcause it or narrow down the case. Also, once compiled on Suse-64, will it run fine across all other OS-es – Redhat, Ubuntu, etc. - if not, please provide a minimal example BTW, it's not necessary to explicitly CC any maintainers of the module - they are subscribed to rt.cpan.org anyway. Cheers, Roderich

Wed May 07 09:36:55 2014 RSCHUPP [...] cpan.org - Correspondence added

On 2014-05-07 08:21:31, angan.das@intel.com wrote: Show quoted text

> /usr/bin/perl -v > This is perl, v5.8.8 built for x86_64-linux-thread-multi

... Show quoted text

> our environment by the env-team. And so what it implies is its already > installed property and tested. > /usr/intel/pkgs/perl/5.14.1/bin/pp

Then the above Perl version is irrelevant (that's the distro's Perl), this PAR::Packer (including the pp Perl script) were most likely built against a local (though pre-packaged) Perl installation (guessing from the filename, Perl 5.14.1). Could you please provide the output of "/usr/intel/pkgs/perl/5.14.1/bin/perl -v" and "/usr/intel/pkgs/perl/5.14.1/bin/perl -V". Also check that the first line of /usr/intel/pkgs/perl/5.14.1/bin/pp is #!/usr/intel/pkgs/perl/5.14.1/bin/perl I'm pretty confident that PAR::Packer builds (and works) correctly for the distro Perl of any major Linux distro (Redhat, Suse, Debian etc - some might even package PAR::Packer), but locally built Perl installations might be broken in subtle ways. This might not show with most Perl modules, but PAR::Packer is very peculiar and unlike any other Perl module. That's why I asked for the "hello world" example. If this doesn't run in any scenario, you're PAR::Packer installation is definitely broken. Show quoted text

> - does the problem happen with a trivial script, e.g. > > $ pp -o hello.exe -e 'print "hello, world\n"' > $ ./hello.exe > Yes and no both. I tried running it on a different setup (basically > some shell variables set) and it ran fine. I tried running it on a > fresh xterm and it ran fine. However, its failing in some particular > xterm in some particular setup.

When it fails - what's the error message? Things to look out for are environment variables PERL5LIB (generally anything starting with PERL), PATH, LD_LIBRARY_PATH. Though - at least in theory - the resulting executable should be immune to these. Show quoted text

> Also, once compiled on Suse-64, will it run fine across all other OS- > es – Redhat, Ubuntu, etc.

Yes. It's as portable to any other 64-bit Linux on the same hardware architecture as any executable that you built by compiling and linking a, say, C program. BTW, pp is not *compiling* your script in any way - it packs up the perl executable and all modules used (recursively) by your script into a zip and prepends the zip with a small program that will extract the stuff into a temp directory and run it from there. Cheers, Roderich

Wed May 07 11:41:43 2014 angan.das [...] intel.com - Correspondence added

Subject:	RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Date:	Wed, 7 May 2014 15:41:28 +0000
To:	"bug-PAR-Packer [...] rt.cpan.org" <bug-PAR-Packer [...] rt.cpan.org>
From:	"Das, Angan" <angan.das [...] intel.com>

Roderich, Thanks for the quick response. Follow-up responses below: - Angan Show quoted text

-----Original Message----- From: Roderich Schupp via RT [mailto:bug-PAR-Packer@rt.cpan.org] Sent: Wednesday, May 07, 2014 6:37 AM To: Das, Angan Subject: [rt.cpan.org #95417] Perl pp error: Seeking some info <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 > On 2014-05-07 08:21:31, angan.das@intel.com<mailto:angan.das@intel.com> wrote:

> /usr/bin/perl -v > This is perl, v5.8.8 built for x86_64-linux-thread-multi

...

> our environment by the env-team. And so what it implies is its already > installed property and tested. > /usr/intel/pkgs/perl/5.14.1/bin/pp

Then the above Perl version is irrelevant (that's the distro's Perl), this PAR::Packer (including the pp Perl script) were most likely built against a local (though pre-packaged) Perl installation (guessing from the filename, Perl 5.14.1). Could you please provide the output of "/usr/intel/pkgs/perl/5.14.1/bin/perl -v" and "/usr/intel/pkgs/perl/5.14.1/bin/perl -V".

> /usr/intel/pkgs/perl/5.14.1/bin/perl -v

This is perl 5, version 14, subversion 1 (v5.14.1) built for x86_64-linux

> /usr/intel/pkgs/perl/5.14.1/bin/perl -V

Summary of my perl5 (revision 5 version 14 subversion 1) configuration: Platform: osname=linux, osvers=2.6.16.60-0.58.1.1290.1.ptf.600981-smp, archname=x86_64-linux uname='linux plxc4090 2.6.16.60-0.58.1.1290.1.ptf.600981-smp #1 smp wed dec 2 12:27:56 utc 2009 x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr/intel/pkgs/perl/5.14.1 -Dprivlib=/usr/intel/pkgs/perl/5.14.1/lib64/5.14.1 -Dsitelib=/usr/intel/pkgs/perl/5.14.1/lib64/site_perl -Dotherlibdirs=/usr/intel/pkgs/perl/5.14.1/lib64/module/default -Dlibs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -Dfull_csh=/usr/intel/bin/tcsh -Dfull_sed=/usr/intel/bin/gsed -Dlocincpth=/include /include -Dloclibpth= -Duseshrplib -Dcc=/usr/intel/pkgs/gcc/4.5.2/bin/gcc -Dccflags= -O2 -fPIC -I/usr/intel/pkgs/perl/5.14.1/include -L/usr/intel/pkgs/perl/5.14.1/lib64 -Wl,-rpath=/usr/intel/pkgs/perl/5.14.1/lib64 -Dldflags= -L/usr/intel/pkgs/perl/5.14.1/lib64 -Wl,-rpath=/usr/intel/pkgs/perl/5.14.1/lib64' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef ……. Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF Built under linux Compiled at Nov 10 2011 08:25:50 %ENV: PERL5LIB="/p/foundry/eda/em64t_SLES10/oascript/v1.0-2011.10.19/perl5:/p/foundry/env/lib/perl/1.11/em64t_SLES10/lib:/p/foundry/env/lib/perl/1.11/em64t_SLES10/lib/site_perl:/p/foundry/env/proj_utils/lib/perl" @INC: /p/foundry/eda/em64t_SLES10/oascript/v1.0-2011.10.19/perl5 /p/foundry/env/lib/perl/1.11/em64t_SLES10/lib/5.14.1 /p/foundry/env/lib/perl/1.11/em64t_SLES10/lib /p/foundry/env/lib/perl/1.11/em64t_SLES10/lib/site_perl/5.14.1 /p/foundry/env/lib/perl/1.11/em64t_SLES10/lib/site_perl/x86_64-linux /p/foundry/env/lib/perl/1.11/em64t_SLES10/lib/site_perl /p/foundry/env/proj_utils/lib/perl /usr/intel/pkgs/perl/5.14.1/lib64/site_perl/x86_64-linux /usr/intel/pkgs/perl/5.14.1/lib64/site_perl /usr/intel/pkgs/perl/5.14.1/lib64/5.14.1/x86_64-linux /usr/intel/pkgs/perl/5.14.1/lib64/5.14.1 /usr/intel/pkgs/perl/5.14.1/lib64/module/default/x86_64-linux /usr/intel/pkgs/perl/5.14.1/lib64/module/default Also check that the first line of /usr/intel/pkgs/perl/5.14.1/bin/pp is #!/usr/intel/pkgs/perl/5.14.1/bin/perl YES, it is so. All packages as per directory name are as per the Perl version. I'm pretty confident that PAR::Packer builds (and works) correctly for the distro Perl of any major Linux distro (Redhat, Suse, Debian etc - some might even package PAR::Packer), but locally built Perl installations might be broken in subtle ways. This might not show with most Perl modules, but PAR::Packer is very peculiar and unlike any other Perl module. That's why I asked for the "hello world" example. If this doesn't run in any scenario, you're PAR::Packer installation is definitely broken. As I said earlier, it does work.

> - does the problem happen with a trivial script, e.g. > > $ pp -o hello.exe -e 'print "hello, world\n"' > $ ./hello.exe > Yes and no both. I tried running it on a different setup (basically > some shell variables set) and it ran fine. I tried running it on a > fresh xterm and it ran fine. However, its failing in some particular > xterm in some particular setup.

When it fails - what's the error message? As per my earlier email, $ <output>.exe --help Attempt to reload Scalar/Util.pm aborted. Compilation failed in require at /usr/intel/pkgs/perl/5.14.1/lib64/5.14.1/Compress/Zlib.pm line 8. BEGIN failed--compilation aborted at /usr/intel/pkgs/perl/5.14.1/lib64/5.14.1/Compress/Zlib.pm line 8. Compilation failed in require at -e line 358. Things to look out for are environment variables PERL5LIB (generally anything starting with PERL), PATH, LD_LIBRARY_PATH. Though - at least in theory - the resulting executable should be immune to these.

> Also, once compiled on Suse-64, will it run fine across all other OS- > es – Redhat, Ubuntu, etc.

Yes. It's as portable to any other 64-bit Linux on the same hardware architecture as any executable that you built by compiling and linking a, say, C program. BTW, pp is not *compiling* your script in any way - it packs up the perl executable and all modules used (recursively) by your script into a zip and prepends the zip with a small program that will extract the stuff into a temp directory and run it from there. Could you give a pointer to the temp file/directory created? Cheers, Roderich

Wed May 07 16:23:54 2014 RSCHUPP [...] cpan.org - Correspondence added

On 2014-05-07 11:41:43, angan.das@intel.com wrote: Show quoted text

> > /usr/intel/pkgs/perl/5.14.1/bin/perl -V

... Show quoted text

> %ENV: > PERL5LIB="/p/foundry/eda/em64t_SLES10/oascript/v1.0- > 2011.10.19/perl5:/p/foundry/env/lib/perl/1.11/em64t_SLES10/lib:/p/foundry/env/lib/perl/1.11/em64t_SLES10/lib/site_perl:/p/foundry/env/proj_utils/lib/perl"

Dunno what's in these trees. Just to rule out any interference, can you please $ unset PERL5LIB # rebuild and check the "hello world" example $ pp -o hello.exe -e 'print "hello world\n"' $ ./hello.exe If this still fails, your installation of PAR::Packer is broken. Show quoted text

> Could you give a pointer to the temp file/directory created?

The per-user, per-packed-executable temp directory is ${TMPDIR-/tmp}/par-<USER>/<SHA1> Cheers, Roderich

Fri May 30 12:41:42 2014 angan.das [...] intel.com - Correspondence added

Subject:	RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Date:	Fri, 30 May 2014 16:41:31 +0000
To:	"bug-PAR-Packer [...] rt.cpan.org" <bug-PAR-Packer [...] rt.cpan.org>
From:	"Das, Angan" <angan.das [...] intel.com>

Is there any way to pack all the modules/packages also in the compiled script? For e.g., remove all /usr/bin/ kind of dependencies b'cos I see them as strings inside the compiled binary. And when I remove those paths (since it needs to be shipped to an external customer) thru hacky edits, I see a segmentation fault during my run. - Angan Show quoted text

-----Original Message----- From: Roderich Schupp via RT [mailto:bug-PAR-Packer@rt.cpan.org] Sent: Wednesday, May 07, 2014 1:24 PM To: Das, Angan Subject: [rt.cpan.org #95417] Perl pp error: Seeking some info <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 > On 2014-05-07 11:41:43, angan.das@intel.com wrote:

> > /usr/intel/pkgs/perl/5.14.1/bin/perl -V

...

> %ENV: > PERL5LIB="/p/foundry/eda/em64t_SLES10/oascript/v1.0- > 2011.10.19/perl5:/p/foundry/env/lib/perl/1.11/em64t_SLES10/lib:/p/foundry/env/lib/perl/1.11/em64t_SLES10/lib/site_perl:/p/foundry/env/proj_utils/lib/perl"

Dunno what's in these trees. Just to rule out any interference, can you please $ unset PERL5LIB # rebuild and check the "hello world" example $ pp -o hello.exe -e 'print "hello world\n"' $ ./hello.exe If this still fails, your installation of PAR::Packer is broken.

> Could you give a pointer to the temp file/directory created?

The per-user, per-packed-executable temp directory is ${TMPDIR-/tmp}/par-<USER>/<SHA1> Cheers, Roderich

Fri May 30 13:40:24 2014 angan.das [...] intel.com - Correspondence added

Subject:	RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Date:	Fri, 30 May 2014 17:39:26 +0000
To:	"bug-PAR-Packer [...] rt.cpan.org" <bug-PAR-Packer [...] rt.cpan.org>
From:	"Das, Angan" <angan.das [...] intel.com>

For e.g. attached is the file containing grep of all *intel* strings out of my pp compiled binary. I want to know if there are any dependencies on these paths. For e.g., whether the binary/compiled/packed script will break on some non-Intel environment. And if not, why does it break and give segmentation fault when I search-and-replace all "/usr/intel" within it to "/usr/test" and rerun the script in Intel environment (during my testing)? - Angan Show quoted text

-----Original Message----- From: Das, Angan Sent: Friday, May 30, 2014 9:41 AM To: 'bug-PAR-Packer@rt.cpan.org' Subject: RE: [rt.cpan.org #95417] Perl pp error: Seeking some info Is there any way to pack all the modules/packages also in the compiled script? For e.g., remove all /usr/bin/ kind of dependencies b'cos I see them as strings inside the compiled binary. And when I remove those paths (since it needs to be shipped to an external customer) thru hacky edits, I see a segmentation fault during my run. - Angan

-----Original Message----- From: Roderich Schupp via RT [mailto:bug-PAR-Packer@rt.cpan.org] Sent: Wednesday, May 07, 2014 1:24 PM To: Das, Angan Subject: [rt.cpan.org #95417] Perl pp error: Seeking some info <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 > On 2014-05-07 11:41:43, angan.das@intel.com wrote:

> > /usr/intel/pkgs/perl/5.14.1/bin/perl -V

...

> %ENV: > PERL5LIB="/p/foundry/eda/em64t_SLES10/oascript/v1.0- > 2011.10.19/perl5:/p/foundry/env/lib/perl/1.11/em64t_SLES10/lib:/p/foundry/env/lib/perl/1.11/em64t_SLES10/lib/site_perl:/p/foundry/env/proj_utils/lib/perl"

Dunno what's in these trees. Just to rule out any interference, can you please $ unset PERL5LIB # rebuild and check the "hello world" example $ pp -o hello.exe -e 'print "hello world\n"' $ ./hello.exe If this still fails, your installation of PAR::Packer is broken.

> Could you give a pointer to the temp file/directory created?

The per-user, per-packed-executable temp directory is ${TMPDIR-/tmp}/par-<USER>/<SHA1> Cheers, Roderich

Message body is not shown because sender requested not to inline it.

Fri May 30 17:44:45 2014 RSCHUPP [...] cpan.org - Correspondence added

On 2014-05-30 13:40:24, angan.das@intel.com wrote: Show quoted text

> For e.g. attached is the file containing grep of all *intel* strings > out of my pp compiled binary. > > I want to know if there are any dependencies on these paths.

No. The packed executable is self-contained and doesn't need anything from the original packing site. The strings you saw are # line commentes (see the perlsyn man page for "Plain Old Comments"). Their purpose is so that die() or warn() messages mention the original filename and line number though the actual files when running the executable may have totally different names (or might not be files at all). BTW regarding "my pp compiled binary": pp does *not* compile your perl script in any way. Think of the resulting executable a self-extracting archive that contains your script, any required modules and even a perl binary. Cheers, Roderich

Fri May 30 17:48:25 2014 angan.das [...] intel.com - Correspondence added

Subject:	RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Date:	Fri, 30 May 2014 21:48:07 +0000
To:	"bug-PAR-Packer [...] rt.cpan.org" <bug-PAR-Packer [...] rt.cpan.org>
From:	"Das, Angan" <angan.das [...] intel.com>

Roderich, Thanks for the help. This brings me to my earlier 2nd question --- If they are truly comments, why do I get segmentation fault when I search-and-replace all "intel" with "TEST" (things however pass with "intel" changed to "INTEL"). Could you kindly take a look at the grepped "intel" strings (file re-attached) and let me know. - Angan Show quoted text

-----Original Message----- From: Roderich Schupp via RT [mailto:bug-PAR-Packer@rt.cpan.org] Sent: Friday, May 30, 2014 2:45 PM To: Das, Angan Subject: [rt.cpan.org #95417] Perl pp error: Seeking some info <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 > On 2014-05-30 13:40:24, angan.das@intel.com wrote:

> For e.g. attached is the file containing grep of all *intel* strings > out of my pp compiled binary. > > I want to know if there are any dependencies on these paths.

No. The packed executable is self-contained and doesn't need anything from the original packing site. The strings you saw are # line commentes (see the perlsyn man page for "Plain Old Comments"). Their purpose is so that die() or warn() messages mention the original filename and line number though the actual files when running the executable may have totally different names (or might not be files at all). BTW regarding "my pp compiled binary": pp does *not* compile your perl script in any way. Think of the resulting executable a self-extracting archive that contains your script, any required modules and even a perl binary. Cheers, Roderich

Message body is not shown because sender requested not to inline it.

Fri May 30 17:57:26 2014 RSCHUPP [...] cpan.org - Correspondence added

On 2014-05-30 17:48:25, angan.das@intel.com wrote: Show quoted text

> If they are truly comments, why do I get segmentation fault when I > search-and-replace all "intel" with "TEST" (things however pass with > "intel" changed to "INTEL").

Because you destroy the integrity of the data structure of the packed executable. You must not modify it in any way. Cheers, Roderich

Fri May 30 18:01:56 2014 angan.das [...] intel.com - Correspondence added

Subject:	RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Date:	Fri, 30 May 2014 22:01:43 +0000
To:	"bug-PAR-Packer [...] rt.cpan.org" <bug-PAR-Packer [...] rt.cpan.org>
From:	"Das, Angan" <angan.das [...] intel.com>

If it is a comment, I am not sure what " integrity" is lost when I change /usr/intel/bin/ to /usr/TEST/bin. Either it is relying on the path or it is not. Could you please see the non-comment lines like the ones below. Why is "gcc" coming in the picture? /usr/intel/pkgs/perl/5.14.1/lib64/site_perl/x86_64-linux /usr/intel/pkgs/perl/5.14.1/lib64/site_perl /usr/intel/pkgs/perl/5.14.1/lib64/5.14.1/x86_64-linux archlib='/usr/intel/pkgs/perl/5.14.1/lib64/5.14.1/x86_64-linux' archlibexp='/usr/intel/pkgs/perl/5.14.1/lib64/5.14.1/x86_64-linux' bin='/usr/intel/pkgs/perl/5.14.1/bin' binexp='/usr/intel/pkgs/perl/5.14.1/bin' cc='/usr/intel/pkgs/gcc/4.5.2/bin/gcc' ccdlflags='-Wl,-E -Wl,-rpath,/usr/intel/pkgs/perl/5.14.1/lib64/5.14.1/x86_64-linux/CORE' ccflags='-O2 -fPIC -I/usr/intel/pkgs/perl/5.14.1/include -L/usr/intel/pkgs/perl/5.14.1/lib64 -Wl,-rpath=/usr/intel/pkgs/perl/5.14.1/lib64 -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' cf_by='usrintel' - Angan Show quoted text

-----Original Message----- From: Roderich Schupp via RT [mailto:bug-PAR-Packer@rt.cpan.org] Sent: Friday, May 30, 2014 2:57 PM To: Das, Angan Subject: [rt.cpan.org #95417] Perl pp error: Seeking some info <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 > On 2014-05-30 17:48:25, angan.das@intel.com wrote:

> If they are truly comments, why do I get segmentation fault when I > search-and-replace all "intel" with "TEST" (things however pass with > "intel" changed to "INTEL").

Because you destroy the integrity of the data structure of the packed executable. You must not modify it in any way. Cheers, Roderich

Fri May 30 18:12:32 2014 RSCHUPP [...] cpan.org - Correspondence added

On 2014-05-30 18:01:56, angan.das@intel.com wrote: Show quoted text

> If it is a comment, I am not sure what " integrity" is lost when I > change /usr/intel/bin/ to /usr/TEST/bin.

Read "Anatomy of a Self-Contained PAR executable" in PAR/Tutorial.pod. BTW, rt.cpan.org is a *bug tracker*, not a help forum or a discussion list. Please keep this to actual bugs. For all other purposes, use the mailing list par@perl.org Cheers, Roderich

Sun Nov 02 08:53:33 2014 RSCHUPP [...] cpan.org - Correspondence added

No more follow up by submitter, closing this bug. Cheers, Roderich

Sun Nov 02 08:53:38 2014 RSCHUPP [...] cpan.org - Status changed from 'open' to 'resolved'