"loadable library" mismatch on new installation

[halfcountplus]

I have a project which uses a number of XS modules; this is something I developed over a few years and released publicly, but have never considered it to be of much interest to others: http://perl-sloop.net/; I just wanted to see it through from start to a particular finish. I do think it's the greatest thing since sliced bread and use it wherever I need a web server (including that site), but all this is mostly besides the point.

By far the most unpleasant part of that experience was creating portable packages for the XS modules, which mostly ended up as an adventure in cargo-cult style reliance on ExtUtils::MakeMaker with simple Makefile.PL's like this:

use 5.010000;
use ExtUtils::MakeMaker;

WriteMakefile (
        NAME => 'Sloop::Socket::Standard',
        VERSION_FROM => 'lib/Sloop/Socket/Standard.pm',
        MIN_PERL_VERSION => 5.10.0,
        CCFLAGS => '-Wall -g -O2 --std=gnu99',
        INC => '-I.',
        NO_META => 1,
        NO_MYMETA => 1
);

And a version of ppport.h that I created or copied from somewhere at some point.

Anyway, that's the backstory, here's the problem: I recently installed this on an ARMv6 machine (Raspberry Pi) running a version of Debian 8. I've had Pi's almost as long as I've had Sloop, and never had a problem using the tarball from my website to install it. Same thing this time.

However, for unrelated reasons, the system had to be upgraded to Debian "stretch"/testing, aka., what will be Debian 9, which upgraded perl from 5.20.2 to 5.22.1, and I had to then rebuild Sloop.

The modules build, then they're installed before testing because some of the tests are circular and/or a bit of laziness is involved at this point (not a big concern since, as mentioned, this is not a project I've ever expected anyone else to take interest in). Unfortunately, what then happens when I go run the tests is:

Lib.c: loadable library and perl binaries are mismatched (got handshak
+e key 0x9200080, needed 0x9400080)

Note the "Lib.c" here presumably refers to part of the Sloop::Lib module. This happens nearly right away, before any of the actual .t tests are ran, when a check is done by the installer:

eval { load Sloop::Client };

Sloop::Client is pure perl but makes use of Sloop::Lib, which has XS bits, and this is the first point where those are needed.

Any other similar test/example requiring the compiled XS code produces the same problem. Note, with a bit of re-iteration:

• The whole installation is new, Sloop was installed initially once, worked fine, then the dist-upgrade to testing which is when it had to be rebuilt.
• My whole understanding of ExtUtils::MakeMaker is negligible, although I am very comfortable with perl, C, and to a lesser extent XS code.

Where do I start diagnosing this problem? I am very willing to abandon ExtUtils::MakeMaker and use some other method -- I really don't care.

[Anonymous Monk]

    CCFLAGS => '-Wall -g -O2 --std=gnu99',

I recall MakeMaker replaces CCFLAGS, instead of adding to them. For example, on my system

$ $ perl -MConfig -E 'say $Config{ccflags}'
-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/loc
+al/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOUR
+CE=2

I think compiling XS with wrong CCFLAGS (that don't match the perl's ones) is likely to cause some problems with perl interp size, which is what is mismatched in your .so file (and also other problems). Try:

use Config;

...
   CCFLAGS => "--std=gnu99 $Config{ccflags}", # if that works, add oth
+er stuff, like -g and -Wall...
...

That's just an idea, so let us know if that works.

[halfcountplus]

Thanks for the tip. Unfortunately, other aspects of upgrading completely from jessie to testing/stretch made it not worthwhile vs. the justification (I wanted the `-J` switch available with newer versions of `lsblk`), so since there wasn't much to loose I've scratched the system and put it back to Raspbian 8.

You have given me something to think about and look into in terms of my packaging though. A point slightly contra this theory, though, is that it worked fine with 5.20.2, some machine, same distro. This doesn't mean it isn't a factor though, see the part of my second response to Anon monk #1 regarding reports of the same problem online clustered last year and all involving 5.22: Re^4: "loadable library" mismatch on new installation.

[Anonymous Monk]

Where do I start diagnosing this problem?

Its not needed, you need to reinstall the "XS" module, that is all

[halfcountplus]

Where would like me to re-install it to, lol? Perhaps I should have clarified that by "rebuilt" I meant "build and installed" (actually if you pay attention when reading the question, that is stated pretty clearly). The .so file is right where it is supposed to be.

If you have any understanding of this stuff at all, it would be nice if you could explain in specific terms what the error means. It certainly does not mean something was not found, etc. It states unequivocally it is mismatched. Beyond that I just sense you are shooting blanks for no reason...

[Anonymous Monk]

From perldiag

%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