Re^3: "loadable library" mismatch on new installation

%s: loadable library and perl binaries are mismatched (got handshake key %p, needed %p)

(P) A dynamic loading library .so or .dll was being loaded into the process that was built against a different build of perl than the said library was compiled against. Reinstalling the XS module will likely fix this error.

One perl built the .so, and a different perl is trying to run it, use the different perl to build the .so and it should work

Comment on Re^3: "loadable library" mismatch on new installation

Replies are listed 'Best First'.
Re^4: "loadable library" mismatch on new installation by halfcountplus (Hermit) on Apr 12, 2016 at 13:34 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^4: "loadable library" mismatch on new installation
by halfcountplus (Hermit) on Apr 12, 2016 at 13:34 UTC

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.

[reply]