[rt.cpan.org #95417] Perl pp error: Seeking some info

[Das, Angan via RT]

Tue May 06 16:51:45 2014: Request 95417 was acted upon.
Transaction: Ticket created by ***@intel.com
Queue: PAR
Subject: Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >



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

[Roderich Schupp via RT]

Wed May 07 04:23:39 2014: Request 95417 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >

Post by Das, Angan via RT
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

[Das, Angan via RT]

Wed May 07 08:21:31 2014: Request 95417 was acted upon.
Transaction: Correspondence added by ***@intel.com
Queue: PAR-Packer
Subject: RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >


Roderich,

Thanks for the prompt response. Given below are my inline answers:

-----Original Message-----
From: Roderich Schupp via RT [mailto:bug-PAR-***@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 >

Post by Das, Angan via RT
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

[Roderich Schupp via RT]

Wed May 07 09:36:55 2014: Request 95417 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >

Post by Das, Angan via RT
/usr/bin/perl -v
This is perl, v5.8.8 built for x86_64-linux-thread-multi

...

Post by Das, Angan via RT
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.

Post by Das, Angan via RT
- 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.

Post by Das, Angan via RT
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

[Das, Angan via RT]

Wed May 07 11:41:43 2014: Request 95417 was acted upon.
Transaction: Correspondence added by ***@intel.com
Queue: PAR-Packer
Subject: RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >


Roderich,

Thanks for the quick response. Follow-up responses below:

- Angan

-----Original Message-----
From: Roderich Schupp via RT [mailto:bug-PAR-***@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 >

Post by Das, Angan via RT
/usr/bin/perl -v
This is perl, v5.8.8 built for x86_64-linux-thread-multi

...

Post by Das, Angan via RT
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".

Post by Das, Angan via RT
/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

Post by Das, Angan via RT
/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.

Post by Das, Angan via RT
- 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.

Post by Das, Angan via RT
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

[Roderich Schupp via RT]

Wed May 07 16:23:54 2014: Request 95417 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >

Post by Das, Angan via RT

Post by Roderich Schupp via RT
/usr/intel/pkgs/perl/5.14.1/bin/perl -V

...

Post by Das, Angan via RT
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.

Post by Das, Angan via RT
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

[Das, Angan via RT]

Fri May 30 12:41:42 2014: Request 95417 was acted upon.
Transaction: Correspondence added by ***@intel.com
Queue: PAR-Packer
Subject: RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >


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-***@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 >

Post by Das, Angan via RT

Post by Roderich Schupp via RT
/usr/intel/pkgs/perl/5.14.1/bin/perl -V

...

Post by Das, Angan via RT
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.

Post by Das, Angan via RT
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

[Das, Angan via RT]

Fri May 30 13:40:24 2014: Request 95417 was acted upon.
Transaction: Correspondence added by ***@intel.com
Queue: PAR-Packer
Subject: RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >


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

-----Original Message-----
From: Das, Angan
Sent: Friday, May 30, 2014 9:41 AM
To: 'bug-PAR-***@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-***@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 >

Post by Das, Angan via RT

Post by Roderich Schupp via RT
/usr/intel/pkgs/perl/5.14.1/bin/perl -V

...

Post by Das, Angan via RT
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.

Post by Das, Angan via RT
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

[Roderich Schupp via RT]

Fri May 30 17:44:45 2014: Request 95417 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >

Post by Das, Angan via RT
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

[Das, Angan via RT]

Fri May 30 17:48:25 2014: Request 95417 was acted upon.
Transaction: Correspondence added by ***@intel.com
Queue: PAR-Packer
Subject: RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >


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

-----Original Message-----
From: Roderich Schupp via RT [mailto:bug-PAR-***@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 >

Post by Das, Angan via RT
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

[Roderich Schupp via RT]

Fri May 30 17:57:26 2014: Request 95417 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >

Post by Das, Angan via RT
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

[Das, Angan via RT]

Fri May 30 18:01:56 2014: Request 95417 was acted upon.
Transaction: Correspondence added by ***@intel.com
Queue: PAR-Packer
Subject: RE: [rt.cpan.org #95417] Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >


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

-----Original Message-----
From: Roderich Schupp via RT [mailto:bug-PAR-***@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 >

Post by Das, Angan via RT
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

[Roderich Schupp via RT]

Fri May 30 18:12:32 2014: Request 95417 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >

Post by Das, Angan via RT
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 ***@perl.org

Cheers, Roderich

[Roderich Schupp via RT]

Sun Nov 02 08:53:33 2014: Request 95417 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Perl pp error: Seeking some info
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@intel.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=95417 >


No more follow up by submitter, closing this bug.

Cheers, Roderich