Fair enough. However, it is not possible that is the case here. The install path for the first version was `/usr/local/lib/perl/5.20.2`, whereas for the second version it was `.../5.22.1`. Although it did not show up in `@INC` on the new perl, I in fact moved the 5.20.2 completely anyway, and yes, all the modules did show up as installed in 5.22.1 (with appropriate timestamps). Since it was a brand new system, there is no possibility that there was some old installation lying around somewhere. There was only one such .so available, the one that had been just built using the same perl that complained about the mismatch.

If you search for this error on the internet ("loadable library and perl binaries are mismatched") what is interesting is that there is NOT really a long history of reports in the way that is typical of perl. Almost all of them are from 2015 and pertain to 5.22, and they fall into two categories:

• User bug reports of build failures on existing applications/modules that had previously worked -- for at least one of these, the fix was a patch to ExtUtils::MakeMaker.
• Mail archive discussion amongst people I presume are maintainers of related parts implying there was a bug involved that may have been fixed. Note I don't have this problem with perl 5.22.1 on an x86-64 build.

I think it is most likely something along the lines of what Anonymous Monk #2 suggested: Re: "loadable library" mismatch on new installation, i.e., a combination of some "bug like" behaviour coupled with my ignorance of exactly how the build process occurs.