We don't bite newbies here... much | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Right, lets go back to basics. Some perl modules, including some core ones, contain a mixture of both C and Perl. The perl code usually resides in the file Foo.pm, while the C code resides in Foo.xs. When the module is installed (or for a core module, when perl is built), the .xs file is compiled into a Foo.so library file. Foo.pm will usually have a line in it like $Foo::VERSION = 1.21. Similary, that version number will compiled into the .so object.
At runtime, when code does 'use Foo;', Foo.pm is loaded and executed; Foo.pm will then call Dynaloader.pm to do the clever stuff related to linking the Foo.so object into the perl runtime. At this point, Dynaloader checks whether $Foo::VERSION matches the version in the .so file, and if not dies with the error you're seeing. Some further pertinant facts: the version of IO bundled with all recent perls (5.8.1-5.8.7, 5.9.0-5.9.2) is 1.21; however, there is a newer version available on CPAN, 1.22. I would conclude therefore, that on some of your testers' machines, they have somehow (perhaps automatically) downloaded IO-1.22 from CPAN and partially or fully installed it somewhere on their system; that your test code or something that calls your test code, is directly or indirectly useing or requiring IO; and that the various library search paths and environment variables at this point are such that the built-in IO.pm 1.21 but also the external IO.so 1.22 are being found. Possibly (but not necessarily) related to how your module sets up or modifies such paths. Dave. In reply to Re: More on "IO object version does not match bootstrap parameter" error
by dave_the_m
|
|