in reply to Re: 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)

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.

🦛

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

Replies are listed 'Best First'.
Re^3: XS.c: loadable library and perl binaries are mismatched (got handshake key 0xc100000, needed 0xc180000)
by syphilis (Archbishop) on Jul 29, 2020 at 11:54 UTC
    ..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
[reply]

      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

      [download]

      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

      [download]

      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

[reply]
[d/l]
[select]
        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
[reply]

In Section Seekers of Perl Wisdom