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

This suggests that a useful mechanism would be to have "pre-tests" that check out the environment. If a pre-test failed, then the main test results (positive or negative) would not be reported, and the tester would be informed of the problem.

And then, to go with this, we'd want a standard Test::Sanity or Test::Configuration or Test::NotMyFault that people could submit their checks too, so it could gradually accrete tests for the most common misconfigurations that CPAN authors have been unfairly blamed for.

Finally, we'd need... well... someone to actually implement those two suggestions. (/me hides)

I work for Reactrix Systems, and am willing to admit it.

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 Anonymous Monk on Jun 10, 2008 at 19:36 UTC
I found a strange source of similar errors which may not apply in this case, but did drive me crazy for a week. The Encode module, rather than hard-coding VERSION, uses CVS tags for Revision with code to translate that tag into standard numbers. It is nice for developers, I am sure. Unfortunately, I checked some pm files from Encode into my CVS along with other code. The end result being that my CVS changed the revision tag, and thus the apparent version. When the version did not match the .so file, it broke. The only reason I discovered this was that I recompiled, checked the new pm files into CVS and the revision number in the error changed. Now, I am not sure how many other people check third party perl files into their CVS, but this is definitely one possible cause. And since I stumbled across this page while trying to figure out that very problem, I figured I should mention it in case someone else is having the same problem.	[reply]

Replies are listed 'Best First'.

Re^2: More on "IO object version does not match bootstrap parameter" error
by Anonymous Monk on Jun 10, 2008 at 19:36 UTC

I found a strange source of similar errors which may not apply in this case, but did drive me crazy for a week. The Encode module, rather than hard-coding VERSION, uses CVS tags for Revision with code to translate that tag into standard numbers. It is nice for developers, I am sure. Unfortunately, I checked some pm files from Encode into my CVS along with other code. The end result being that my CVS changed the revision tag, and thus the apparent version. When the version did not match the .so file, it broke. The only reason I discovered this was that I recompiled, checked the new pm files into CVS and the revision number in the error changed. Now, I am not sure how many other people check third party perl files into their CVS, but this is definitely one possible cause. And since I stumbled across this page while trying to figure out that very problem, I figured I should mention it in case someone else is having the same problem.

[reply]