http://qs1969.pair.com?node_id=11120036


in reply to Re^3: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000)
in thread XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000)

Hi

I've tried what you suggested (manually installing rather than with cpan). List::MoreUtils required List::MoreUtils::XS so I tried to install that first. The "make test" immediately started spewing out these messages:

"/home/rg8239/perl/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' +-- XS.bs blib/arch/auto/List/MoreUtils/XS/XS.bs 644 PERL_DL_NONLAZY=1 "/home/rg8239/perl/bin/perl" "-MExtUtils::Command::M +M" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; tes t_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/xs/*.t xt/*.t XS.c: loadable library and perl binaries are mismatched (got handshake + key 0xc100000, needed 0xc180000) t/xs/after.t ................ Dubious, test returned 1 (wstat 256, 0x100) No subtests run

so the problem is not with cpan.

You asked about the gcc compiler. It's the same compiler I had used to build 5.20. Also you mentioned the initial perl 5.30.3 installation running flawlessly. Well, pretty close to flawlessly--99.92%...

Failed 2 tests out of 2452, 99.92% okay. ../cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t ../ext/POSIX/t/math.t

the IO::Socket installed and is perfectly usable. The test failed because of a pretty restrictive proxy. The 5.20 install had the exact same test fails but I've had no issues with List::MoreUtils or any other modules so I'm not thinking the math test posed a major problem either

Replies are listed 'Best First'.
Re^5: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000)
by syphilis (Archbishop) on Jul 30, 2020 at 01:19 UTC
    List::MoreUtils required List::MoreUtils::XS so I tried to install that first

    Aaah, yes - the problem is with List-MoreUtils-XS-0.428 and not List-MoreUtils-0.428.

    I think List-MoreUtils will work quite well without List-MoreUtils-XS, so that's an option you might take.
    It would simply mean that, for some of the functions, you'll be using the slower pure-perl version instead of the XS version.

    According to my memory (which may be flawed), I've not seen that "handshake" error issued in relation to generated .c files before.
    It's an error that I associate with .xs files.

    It's also puzzling that the LeakTrace.c file, generated during the Test-LeakTrace-0.16 build, does not suffer the same error.
    Both XS.c and LeakTrace.c were generated from their respective xs files by ExtUtils::ParseXS.
    Each of those .c files begin with a comment that tells you what generated them. I guess you could take a look at those comments and verify that they were both generated by the same version of ExtUtils::ParseXS.

    My main hunch is that, between 5.20 and 5.30, some change has occurred that gcc-3.4.5 can't handle - but I certainly don't rule out the possibility that it's because of something else.
    Maybe try posting to p5p mailing list. Someone there might have an idea on what you can do to overcome the error.
    If it were me, I'd be upgrading gcc to a more recent version of gcc if there's an option to do that. Even gcc-4.6.3 is still building modern perls (up to and including current blead 5.33.0) flawlessly on my debian wheezy system.

    Cheers,
    Rob