RE: PP binary not running with error message: IO object version 1.22 does not match bootstrap parameter 1.23
Both build target systems have 5.8.8. I did one experiment: I uninstalled perl in the target system was able to run the pp binary successfully. I haven't used any hard-coded library paths too in the source code. But still the binary is referring to an installed module on the target system. Thanks Regards, Bharath Veera -Original Message- From: Roderich Schupp [mailto:roderich.sch...@googlemail.com] Sent: Monday, February 23, 2009 5:04 AM To: Veera, Bharath Kumar Cc: par@perl.org Subject: Re: PP binary not running with error message: IO object version 1.22 does not match bootstrap parameter 1.23 On Fri, Feb 20, 2009 at 11:10 AM, Roderich Schupp roderich.sch...@googlemail.com wrote: bash-0.5# ./showinc Fcntl object version 1.05 does not match bootstrap parameter 1.06 at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/DynaLoader.pm line 252. OK, what are the versions of Perl on your build and target systems? The target seems to have Perl 5.8.8. Cheers, Roderich
Re: PP binary not running with error message: IO object version 1.22 does not match bootstrap parameter 1.23
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 from different machine, it failed with errors as follows. bash-0.5# ./showinc Fcntl object version 1.05 does not match bootstrap parameter 1.06 at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/DynaLoader.pm line 252. The problem apparently is that at an early stage the pp´ed executable seems to load something from the target machine rather than from the stuff it has packed in. In your case it has apparently loaded Fnctl.pm from one side and Fnctl.so from the other, but their versions differ and that is recognized by DynaLoader. This has been reported in the past and I thought it was fixed. Maybe some recent regression? Sorry, I´m currently on vacation and have only access to email. I´ll try to pick up on this thread when I´m back. Cheers, Roderich
RE: PP binary not running with error message: IO object version 1.22 does not match bootstrap parameter 1.23
Re-initializing this thread. The problem statement: 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 from different machine, it failed with errors as follows. bash-0.5# ./showinc Fcntl object version 1.05 does not match bootstrap parameter 1.06 at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/DynaLoader.pm line 252. BEGIN failed--compilation aborted at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/Fcntl.pm line 216. Compilation failed in require at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/IO/Seekable.pm line 104. BEGIN failed--compilation aborted at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/IO/Seekable.pm line 104. Compilation failed in require at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/IO/File.pm line 133. BEGIN failed--compilation aborted at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/IO/File.pm line 133. Compilation failed in require at -e line 352. bash-0.5# I'm really looking for some pointers as this has been some major escalation, as my product delivered using pp is not running at the user machine. It would be really great of you in helping me out resolving this issue. Thanks, Bharath -Original Message- From: Veera, Bharath Kumar Sent: Friday, November 21, 2008 9:15 PM To: Roderich Schupp; bob davis Cc: par@perl.org Subject: RE: PP binary not running with error message: IO object version 1.22 does not match bootstrap parameter 1.23 Hi Bob Roderich, Thanks a lot for the quick replies. Roderich, here are the results you had asked for: On the build system :- -- bash-2.05b$ perl -e 'print INC = @INC\n' INC = /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi /opt/perl_32/lib/5.8.8 /opt/perl_32/lib/site_perl/5.8.8/IA64.ARCHREV_0-thread-multi /opt/perl_32/lib/site_perl/5.8.8 /opt/perl_32/lib/site_perl /opt/perl_32/lib/vendor_perl/5.8.8/IA64.ARCHREV_0-thread-multi /opt/perl_32/lib/vendor_perl/5.8.8 /opt/perl_32/lib/vendor_perl . bash-2.05b$ pp -o showinc -e 'print INC = @INC\n' bash-2.05b$ ./showinc INC = CODE(0x4075a860) CODE(0x4075a9d4) On the test system :- -- bash-2.05# ./showinc INC = CODE(0x4075aaa0) CODE(0x4075ac14) bash-2.05# perl -e 'print INC = @INC\n' INC = /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi /opt/perl_32/lib/5.8.8 /opt/perl_32/lib/site_perl/5.8.8/IA64.ARCHREV_0-thread-multi /opt/perl_32/lib/site_perl/5.8.8 /opt/perl_32/lib/site_perl /opt/perl_32/lib/vendor_perl/5.8.8/IA64.ARCHREV_0-thread-multi /opt/perl_32/lib/vendor_perl/5.8.8 /opt/perl_32/lib/vendor_perl . But I didn't get any /tmp/par-/SOMEHASHDIGEST sorts. And PERL5LIB PERLLIB environment variables were not defined at all. Is something wrong on my build system? And YES, I use use lib '../lib'; kind of code, to refer to my other modules in different directory. Does this affect the @INC such that the resultant pp binary fails? If at all I have to use different methonds to refer to the modules in different directories, can you give me some pointers. Thanks a lot for the help. Let me know if you both need any further information. Regards, Bharath Veera -Original Message- From: Roderich Schupp [mailto:roderich.sch...@googlemail.com] Sent: Friday, November 21, 2008 4:15 PM To: Veera, Bharath Kumar Cc: par@perl.org Subject: Re: PP binary not running with error message: IO object version 1.22 does not match bootstrap parameter 1.23 On Wed, Nov 19, 2008 at 8:07 PM, Veera, Bharath Kumar bharath-kumar.ve...@hp.com 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 depend on the things present on the target system. Indeed, this is how it's supposed to work. There are many possible causes why it doesn't. One possible cause was already mentioned by Bob (environment variable PERL5LIB set on target system). Or could be your script or packed modules that manipulate the module search path (@INC), either implicitly like use lib ...; or explicitly like push @INC, ...;. Did you use the latest and greatest version of pp, i.e. PAR::Packer? Could you try the following experiment: - run pp -o showinc -e 'print INC = @INC\n' on the build system - and then run ./showinc on the target system The correct output should only show directory names starting with /tmp/par-/SOMEHASHDIGEST and CODE(...) references. Cheers, Roderich
Re: PP binary not running with error message: IO object version 1.22 does not match bootstrap parameter 1.23
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) What do $ unzip -l showinc and $ strings -a showinc | grep -A 1 ^FILE show? Cheers, Roderich
Re: PP binary not running with error message: IO object version 1.22 does not match bootstrap parameter 1.23
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 depend on the things present on the target system. Indeed, this is how it's supposed to work. There are many possible causes why it doesn't. One possible cause was already mentioned by Bob (environment variable PERL5LIB set on target system). Or could be your script or packed modules that manipulate the module search path (@INC), either implicitly like use lib ...; or explicitly like push @INC, ...;. Did you use the latest and greatest version of pp, i.e. PAR::Packer? Could you try the following experiment: - run pp -o showinc -e 'print INC = @INC\n' on the build system - and then run ./showinc on the target system The correct output should only show directory names starting with /tmp/par-/SOMEHASHDIGEST and CODE(...) references. Cheers, Roderich
Re: PP binary not running with error message: IO object version 1.22 does not match bootstrap parameter 1.23
Could this have something to do with PERL5LIB ? I made a patch to par that basically made it ignore PERL5LIB. I had this problem on win32 because many clients have oracle installed which includes a version of perl and sets the PERL5LIB. bob Veera, Bharath Kumar wrote: Hi, 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: --SNIPPET-- IO object version 1.22 does not match bootstrap parameter 1.23 at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/DynaLoader.pm line 252. Compilation failed in require at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/IO/Handle.pm line 263. BEGIN failed--compilation aborted at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/IO/Handle.pm line 263. Compilation failed in require at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/IO/Seekable.pm line 101. BEGIN failed--compilation aborted at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/IO/Seekable.pm line 101. Compilation failed in require at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/IO/File.pm line 133. BEGIN failed--compilation aborted at /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi/IO/File.pm line 133. Compilation failed in require at -e line 352. --SNIPPET-- I've resolved this issue in two ways: 1. uninstall perl totally without any trace. The binary works ideally. 2. uninstall perl totally without any trace and install the perl again. Now, the binary works perfectly fine. I strongly agree with the first solution as the binary should ideally not depend on the things present on the target system. But with this theory, how does the existing perl version should create a conflict. It would be really really great of you in helping me in resolving this issue. I don't want to recommnet the users of my binary to re-install or uninstall the existing perl setup, as that may get their wrath out. Thanks, Bharath Veera
