Perl troubleshooting error. Base64 bootstrap parameter

user1 @ svrtest >perl 'test'
MIME::Base64 object version 3.13 does not match bootstrap parameter 3.15 at /usr/local/lib/perl5/x86_64-linux/ line 213.

What does this mean?

I found two on the machine. I did an: diff /first/MIME/ /second/MIME/

The only difference in the module is on the 10th line of says

$VERSION = '3.15';

And the other says

$VERSION = '3.13';

Other than that, the remaining 187 lines of code, are identical.  Any insight?

RamblSystems AdminAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

It appears that you might have Perl or some part of the Perl module libraries installed twice on your system and the environment variables and config files that might have been intended to keep them separate have nonetheless been compromised so that Dynaloader goes looking in the "other" installation tree to find code to load.

It would help some to know what the two paths you've labeled "first" and "second" are.
There is only 33 lines of executable code in v3.13 and the rest is its POD documentation.  Most of the executable (XS) code is being loaded from other files.

I suspect the problem you're seeing here stems from what you said in your other open question.
I've been using cpan. But, also move a couple of .pm modules around manually, because there appears to be multiple versions of perl on the redhat system.
RamblSystems AdminAuthor Commented:
Yes. You're exactly right. The other question is posted


Also, I didn't move...but copy. However, I would think that what you said "bad idea", would still apply.

I just don't know how to fix it. But, I don't think two perl installs (first and second as mention) is the problem. I'm thinking my problem could be more similar to:


...which describes a .pm file version not matching the .so version. The other possible problem mentioned there were permissions related, but I think the permissions are fine.

Thanks for your comments. If you have some troubleshooting tips or other insight into this, I'd love to hear them.
Well, the error message you reported almost always means exactly that: the .pm file version does not match the version compiled into the .so file.

The question explored in the Perlmonks thread is: How can this happen?

If you've copied a .pm file without bringing its corresponding .so file, that's one way it could happen.

If you modify @INC in a script such that an already-loaded .so module now has a .pm file in the changed @INC set of paths that is encountered earlier than the .pm which corresponded to the .so module.

If an installation is done with incorrect permissions, a newer .pm file may be hidden so that Perl falls back to finding an older .pm file (but that should have hidden the .so files, too, so I'm not completely certain why the Perlmonks poster found that he had this problem).

If you have a system where Perl is installed in two separate locations, with two different versions, but try to share modules between them by having an @INC component that is in common - an update on one side could introduce a version incompatibility for the other side.


In summary, having two different versions of the module installed on your system is definitely the problem, and it's highly suspect to be related to having two versions of Perl installed or that you've copied .pm modules around.

Fishmonger's "bad idea" assessment applies to the latter.

Whether you're using the Linux distribution's package update methods or CPAN's, the best advice is to try to re-install the modules in question, along with their dependents. Guide the installation process into placing the results in their proper place, but do not move or copy .pm files (that may have .xs or .so files associated with them - this is the sort of thing the build process takes care of).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
RamblSystems AdminAuthor Commented:
Thank you for breaking that down for me. Helped me understand the problem better. Final solution was a permissions problem.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.