Perl DBI.c: loadable library and perl binaries are mismatched

rtwingfield

Well-Known Member

Thanks: 3
Messages: 281

#1
I think it's time for this post, https://forums.freebsd.org/threads/56247/#post-319842, to segue to this forum. (Perhaps a difference audience.)

The problem now is not with a make install failure. The two ports compiled to successful completion. The problem now is that a "handshake key" between the perl5.22.2 and the p5-DBI-1.636, is wrong. Why the mismatch?

If I try to execute a simple perl script that utilizes the DBI, the following error diagnostic:

# perl -T create_roster_db.pl
DBI.c: loadable library and perl binaries are mismatched (got handshake key 0x7ac0080, needed 0x7b80080)



The Wikipedia article, Perl XS, https://en.wikipedia.org/wiki/XS_(Perl), states:
XS is an interface through which a program written in the Perl programming language can call a C or C++ language subroutine. The letters stand for eXternal Subroutine, or xsub, where external means external to Perl, i.e. written in some other language.

. . .XS modules are not without drawbacks. They are difficult to write and maintain, and they may only be installed if a C compiler and the header files that the Perl interpreter was compiled against are available. Also, new versions of Perl may break binary compatibility; if this happens, all XS modules must be recompiled.
. . .so, I have installed the p5-DBI-1.636 Perl5 Database Interface, required for DBD::* modules port, and as you can read above, it chokes.

I have reproduced this scenario on two different FreeBSD v10.2 platforms: a Pentimum-4, and a Dell 8-core 2950.

What to do?
 
OP
OP
rtwingfield

rtwingfield

Well-Known Member

Thanks: 3
Messages: 281

#2
People . . .this is a real problem! Who should I address for an answer. I updated ports. I reinstalled the Perl ports as previoulsly indicated. I (a user) expect it to work. Is anyone using the Perl DBI with MySQL? (. . .I would think so.) If so, what have you done that works, that I'm doing wrong.?
 

ShelLuser

Son of Beastie

Thanks: 1,389
Messages: 2,958

#3
I know this thread is one year old, but today this problem also hit me. I found both a cause and a solution, but truth is that the whole thing still appears somewhat illogical and with that pretty annoying too.

First things first: this usually happens when you rebuild and/or reinstall Perl without doing the same for any libraries which depend on it (you know: pkg info -x p5). In the old days (20141126 from /usr/ports/UPDATING) a mere # portmaster p5- or # portmaster -r perl5- would be able to solve this for you. But not anymore...

I don't know why (my expertise on Perl only goes so far) but these days libraries which seem totally independent will still check for the existence of libraries and will complain when a mismatch is found.

Example: I tried to re-install devel/autoconf and got greeted by a similar error message during building:

Code:
ListUtil.c: loadable library and perl binaries are mismatched (got handshake key
 0x7980080, needed 0x7b00080)
gmake[3]: *** [Makefile:641: autoconf.in] Error 1
I traced this back to List::Util which turns out to be provided by lang/p5-Scalar-List-Utils. So here's where things got a little bizarre for me... While trying to re-build this port I got greeted by the exact same error message. This led up to me believing that this whole thing is by design: any Perl related action can somehow scan all the available libraries and if a mismatch is found it will trigger an error.

Makes sense during Perl execution, but makes less sense (from a user / admin point of view) when you're in the process of re-installing that exact same library!

The solution in this case was somewhat simple: # make deinstall reinstall clean. By first (forcefully) removing the port I also ensured that the library mismatch could no longer be detected (at least not the one involving around ListUtil.c). Then I recompiled & reinstalled the port, thus also re-establishing any dependencies.

As of right now this is pure speculation on my part: Because this error doesn't always occur with every Perl library / module I'm tempted to conclude that some Ports actually do depend on others yet fail to mention this:

Code:
peter@macron:/usr/ports/devel/autoconf#make all-depends-list
/usr/ports/ports-mgmt/pkg
/usr/ports/devel/m4
/usr/ports/print/indexinfo
/usr/ports/misc/help2man
/usr/ports/devel/p5-Locale-gettext
/usr/ports/devel/gettext-tools
/usr/ports/converters/libiconv
/usr/ports/devel/gettext-runtime
/usr/ports/lang/perl5.24
/usr/ports/devel/gmake
/usr/ports/devel/autoconf-wrapper
Considering that this build failed with the error shared earlier, and which got solved by re-installing that Port I'm now led to believe that devel/autoconf also depends on lang/p5-Scalar-List-Utils.

Once again: this is only a theory I have so far and which needs further investigation. For all I know this could also be a "cascading dependency" (can't come up with a better name). So, in other words: one of the Ports mentioned above depends on lang/p5-Scalar-List-Utils and that then led up to the error message during the build of devel/autoconf.

Summing up...
  • Identify the library which causes the error message (in my example above List::Util).
  • Identify the Port responsible for the library (in my example lang/p5-Scalar-List-Utils).
  • De-install then re-install the port ( # make deinstall reinstall clean).
For the record: As said above I know this thread is old, but I can't help wonder if this won't become a recent issue when we'll eventually see a new Perl version emerge.
 
Top