in reply to More on "IO object version does not match bootstrap parameter" error

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.

  • Comment on Re: More on "IO object version does not match bootstrap parameter" error

Replies are listed 'Best First'.
Re^2: More on "IO object version does not match bootstrap parameter" error
by jkeenan1 (Deacon) on Sep 11, 2005 at 20:19 UTC
    Thanks, Dave, for the cogent explanation. That would explain why some testers are reporting the errors and others are not. Of course, that in turn raises the question: How can we encourage our testers to correct such problems?

    As to what in my code is triggering the problem, the most likely candidate is File::Temp, which is used in all files in test suite except the first -- which is the one file that gets through all its tests. But the problem is probably not File::Temp per se but the IO::Handle which File::Temp calls internally.

    I'm loathe to stop using a core module such as File::Temp in my test suite, particularly because part of the testing process is the creation of files and directories which ought to be done in a protected environment such as File::Temp provides. And what about folks who use File::Temp in their module code, not just in their test suites?

    Thanks again for taking the time to think about this problem.

    Jim Keenan

[reply]

      It's probably a problem beyond your control; for example, for the particular failure of ExtUtils-ModuleMaker-0.39, within the same run for this particular testing machine, the same failure was reported for

      Earlier on in this run IO-1.22 was tested, and passed, probably as a result of some other package requiring it. What probably happens is that the build directory for this IO-1.22 gets added to @INC in a way so as to cause this version mis-match within the testers machine.

      Thus, it seems that this failure depends on some other package happening to have a prerequisite of IO that is tested before your package is tested. You can't do very much about that, beyond reporting the problem to the authors of the automated testing software.

[reply]
        I was hoping that someone would know how to cross-check distributions for the presence of this error!

        Thanks, randyk!

        Jim Keenan

[reply]
Re^2: More on "IO object version does not match bootstrap parameter" error
by jkeenan1 (Deacon) on Sep 18, 2005 at 00:58 UTC
    CPAN tester imacat re-tested ExtUtils::ModuleMaker (repeatedly! and on multiple OSes! valiant work) and sent me this message:

    I tested it again and could not reproduce the same failure. However I found that error is caused by the incompatibility from the just-tested IO 1.22 with Perl itself boundled with IO 1.21. Due to some test suite problem it keeps loading the just-tested IO 1.22 from @INC and caused incompatibility problem with Perl itself. I have submit several OK reports on ExtUtils-ModuleMaker, and forwarded this message to Robert Rothenberg, the author of CPAN::YACSmoke.

    Jim Keenan

[reply]

In Section Seekers of Perl Wisdom