Skip Menu |

This queue is for tickets about the PAR CPAN distribution.

Report information
The Basics
Id: 48240
Status: open
Priority: 0/
Queue: PAR

People
Owner: Nobody in particular
Requestors: wfelipe [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.994
Fixed in: (no value)



Subject: MODULE object version 1.YYY does not match $MODULE::VERSION 1.XXX at /usr/lib/perl/5.10/DynaLoader.pm
I'm using Catalyst Framework to generate the PAR package, and I tried to find in other forums, but I couldn't find a final solution. I'm generating the package with the core modules and all additional modules that I need, including DBI.pm (my first problem). Once the package is generated, it's copied to another system (the same perl and operating system version), which also has a DBI.pm, but an older version. When I run the par package, it stops ate the following error: =============== Couldn't instantiate component "MyApp::Model::MyApp", "DBIx::Class::Schema::connection(): No arguments to load_classes and couldn't load DBIx::Class::Storage::DBI (DBI object version 1.605 does not match $DBI::VERSION 1.607 at /usr/lib/perl/5.10/DynaLoader.pm line 219. BEGIN failed--compilation aborted at DBI.pm line 263. Compilation failed in require at DBIx/Class/Storage/DBI.pm line 8. BEGIN failed--compilation aborted at DBIx/Class/Storage/DBI.pm line 8. ) at Catalyst/Model/DBIC/Schema.pm line 318" at ./script/kickstart_server.pl line 58 =============== My guess is that it loads the DBI.pm from the par package, but it prioritize the DBI.so installed in the system, which is an older version. In the par package there are some .so libraries, and one of them was the DBI.so installed in the system which the package was generated. some useful information: - Operating System: Debian Lenny 5.0.2 - perl -v: This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi if you need any information, feel free to ask me
On Mon Jul 27 10:33:43 2009, wfelipe wrote: Show quoted text
> I'm using Catalyst Framework to generate the PAR package, and I tried to > find in other forums, but I couldn't find a final solution. > > I'm generating the package with the core modules and all additional > modules that I need, including DBI.pm (my first problem). Once the > package is generated, it's copied to another system (the same perl and > operating system version), which also has a DBI.pm, but an older version. > > When I run the par package, it stops ate the following error: > =============== > Couldn't instantiate component "MyApp::Model::MyApp", > "DBIx::Class::Schema::connection(): No arguments to load_classes and > couldn't load DBIx::Class::Storage::DBI (DBI object version 1.605 does > not match $DBI::VERSION 1.607 at /usr/lib/perl/5.10/DynaLoader.pm line
219. Show quoted text
> BEGIN failed--compilation aborted at DBI.pm line 263. > Compilation failed in require at DBIx/Class/Storage/DBI.pm line 8. > BEGIN failed--compilation aborted at DBIx/Class/Storage/DBI.pm line 8. > ) at Catalyst/Model/DBIC/Schema.pm line 318" at > ./script/kickstart_server.pl line 58 > =============== > > My guess is that it loads the DBI.pm from the par package, but it > prioritize the DBI.so installed in the system, which is an older > version. In the par package there are some .so libraries, and one of > them was the DBI.so installed in the system which the package was
generated. Show quoted text
> > some useful information: > - Operating System: Debian Lenny 5.0.2 > - perl -v: This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi > > if you need any information, feel free to ask me
another information which may be the behavior that I saw above: in the par package, the *.so files are at lib/auto/<PATH>/MODULE.so, but when I run the application, it's uncompressed at /tmp/par-USER/cache-hash/hash.so, and the DynaLoader loads based on the module name, which overload the original one.
Does the simple example pp -p testdbi -e 'use DBI; print "OK"' (when moved to the machine with a different version of DBI) show the same problem? BTW, it's OK that shared libs are packed with their real name into the .par (or executable), but have mangled hash.so names when extracted into the cache area. PAR patches DynaLoader to make it look for the mangled name.
On Tue Jul 28 06:35:36 2009, RSCHUPP wrote: Show quoted text
> Does the simple example > > pp -p testdbi -e 'use DBI; print "OK"' > > (when moved to the machine with a different version of DBI) > show the same problem? > > BTW, it's OK that shared libs are packed with their real name > into the .par (or executable), but have mangled hash.so names > when extracted into the cache area. PAR patches DynaLoader > to make it look for the mangled name.
The example runs with no problems. Looking deep into the problem, I realized two things: - using strace to read the syscalls to get the stat and open, it always stat the hash.so, and then stat DBI.so installed in the operating system (outside par package), and then open and read DBI.so from the operating system - the module PAR::Heavy, there is a routine override in DynaLoader: *{'DynaLoader::dl_findfile'} = \&_dl_findfile; that override doesn't seem to work, because it's never called
Yeah, seems that "trick DynaLoader into loading the .so with the mangled name from PAR's cache" doesn't work. There was a potentially relevant change in PAR 0.994. Could you downgrade to PAR 0.992 and check whether your problem persists (you'll have to re-pack your executable after downgrading)?