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

Hi,

That looks quite different to what I see on Ubuntu when I cpan -i List::MoreUtils.

I've just noticed gccversion='3.4.5 20051201 (Red Hat 3.4.5-2)'
That is an ancient version of gcc, but I don't know whether that would be the problem.
If gcc-3.4.5 was ok for perl-5.20, I'd guess it should be ok for perl-5.30. (Did perl -V:gccversion report the same with perl-5.20 ?)

Other thoughts:
Why is Test-LeakTrace being built and installed after List-MoreUtils ?
Maybe check which cpan utility is being loaded (which cpan).

I'd probably next try building List-MoreUtils the old fashioned way, just to see what happens:
1) cd into the top level folder of a freshly unpacked List-MoreUtils-0.428.tar.gz;
2) run in sequence, perl Makefile.PL followed by make test;
3) run make install (but only if make test passed).

Is any of that helpful ?

Cheers,
Rob
  • Comment on Re: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000)
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000)
by hippo (Archbishop) on Jul 29, 2020 at 09:59 UTC
    I've just noticed gccversion='3.4.5 20051201 (Red Hat 3.4.5-2)' That is an ancient version of gcc

    Well, rgren925 did say, "I'm installing perl 5.30.3 on RHEL 4 Nahant". That's an O/S from 2005 (and now more than 8 years past EoL) so it is only to be expected that there might be one or two problems compiling and installing something so modern on there. It might not be the entire cause of the problem but is certainly a factor to consider.


    🦛

      ..it is only to be expected that there might be one or two problems compiling and installing something so modern on there

      Yes - but then rgren925 did say that perl-5.30.3 itself was fine. And I assume that means that perl-5.30.0 tested flawlessly. (Perhaps I assume too much :-)

      My first thoughts were along the lines of bliako's suggestion - that there was some remnant of the earlier perl version being found.
      But the @INC directories all include the string "5.30.3" and I don't think it likely that anything from perl-5.20.x would have ended up in a directory that included "5.30.3" as part of its name.

      I think we need a bit more feedback from rgren925.

      Cheers,
      Rob

        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