syphilis has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I've often wondered whether, on Windows, *every* script that dies with a "handshake" error would actually have misbehaved if it had been allowed to continue.
If I had a build of perl that was identical, except that all "handshake" checks were avoided, then I'd be able to know ... and hence the question in the title.
(I'm fairly familiar with building perl on windows - no problems there. It's just a question of how to have a perl that doesn't run any of those pesky "handshake" checks.)

TBC, these "handshake" checks are the ones that result (upon failure) in the script aborting with a diagnostic of something like:
fu.c: loadable library and perl binaries are mismatched (got first handshake key 0000000012e00080, needed 0000000012d00080)

AFTERTHOUGHT:
I suppose I don't really need to avoid them. Just making them "non-fatal on failure" might suffice.
Maybe having them emit warnings, as opposed to actually croaking, might suffice.
However, it would also be nice to avoid having to hack the perl source.

Cheers,
Rob
  • Comment on How do I build perl on Windows such that all "handshake" checks are avoided ?
  • Download Code

Replies are listed 'Best First'.
Re: How do I build perl on Windows such that all "handshake" checks are avoided ?
by dave_the_m (Monsignor) on Oct 13, 2025 at 09:18 UTC
    Another thing that varies between releases is the big interpreter struct. New releases may add a new member somewhere in the middle, or change the size of one of the members. This means that any members beyond that point are misaligned from the perspective of the .so file which was compiled using the old struct definition. This usually manifests itself as most things working fine, then suddenly perl crashes when you try to access $1 or use FETCH or something.

    Dave.

Re: How do I build perl on Windows such that all "handshake" checks are avoided ?
by ikegami (Patriarch) on Oct 13, 2025 at 04:45 UTC

    The check is there to detect versions if the build of Perl which is loading the module is guarantee to have a compatible ABI or not.

    Bypassing would allow the following to happen:

    • Calling the wrong function (Major versions are allowed to reposition functions in the ABI, for example.)
    • Calling a non-existent function (Minor versions are allowed to append functions to the ABI, for example.)
    • Calling a function with incorrect arguments (Most of the functions of MULTIPLICITY builds -- including threaded builds -- take an extra parameter.)
      Yeah - I wasn't thinking of using such a build for "production" purposes.
      And maybe the hack that I described in Re^3: Weird performance issue with Strawberries and Inline::C will, despite behaving correctly on my build of perl-5.42.0, actually fail to behave correctly on my (non-identical but very similar) Strawberry Perl installation of 5.42.0 ... and on my build of current blead.

      The handshake check prevents me from knowing this and I'd like to know ... but there's probably a limit to the trouble to which I'm prepared to go ;-)

      Cheers,
      Rob
        I believe that the handshake check is in the loaded module itself. Something in the XS tooling generates code into the module's .so that hashes various pointers and sizes during module init and then it decides whether to proceed based on whether they match expectations. You'd have to find the code that generates the BOOT function of the .so and make the change there.

        But, as others have pointed out, if the check fails the module is extremely likely to lead to a crash in the interpreter, immediately or eventually.

Re: How do I build perl on Windows such that all "handshake" checks are avoided ?
by ysth (Canon) on Oct 13, 2025 at 15:53 UTC
    These truly do indicate things are very wrong. I'm not sure what making them non-fatal would even look like, other than require failing, and most require/use's are not optional in most programs; seems like even if one such error could be ok to ignore, that your @INC is messed up and there will be some other one also not ok that can't be ignored.