in reply to Re^2: How do I build perl on Windows such that all "handshake" checks are avoided ?
in thread How do I build perl on Windows such that all "handshake" checks are avoided ?

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.

  • Comment on Re^3: How do I build perl on Windows such that all "handshake" checks are avoided ?

Replies are listed 'Best First'.
Re^4: How do I build perl on Windows such that all "handshake" checks are avoided ?
by syphilis (Archbishop) on Oct 14, 2025 at 11:08 UTC
    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

    Yes, and some of us value having all that protective cotton wool wrapped around us.
    But I get annoyed when it stops me from running some small piece of Inline::C code that would (I believe) have executed perfectly well if the failing handshake check had not killed it.

    Anyway, it's not worth the fuss.
    If there was some easy way to build a perl such that the handshake checks were avoided, then I would investigate further.
    But there apparently isn't ... so I won't ;-)

    Cheers,
    Rob
[reply]
      But I get annoyed when it stops me from running some small piece of Inline::C code that would (I believe) have executed perfectly well if the failing handshake check had not killed it
      As an example of why that's not necessarily true, consider a simple XSUB which returns a value. It may return that value using a PADTMP, or it might return it as a mortal SV, which (behind the scenes) pushes a value onto the temps stack and updates the stack index. Between Perl 5.18 and 5.20, the type of the temps stack index changed from 32-bit to 64-bit. A "simple" XSUB compiled under 5.18 and run under 5.20 may well cause the interpreter to SEGV soon after returning.

      Yes, sometimes you might get lucky. But I think the use cases for disabling the check are rare enough that its not worth adding such a feature.

      Dave.

[reply]
        But I think the use cases for disabling the check are rare enough that its not worth adding such a feature.

        Yes - I'm not advocating that such a feature should be added simply because it suits me.
        The pity (from my POV) is that said feature is not already present. Its absence makes it harder for me to satisfy myself that the current policing is not overly oppressive.
        But I will continue to probe at it, as time and inclination allow.

        At the moment, I'm concentrating on this Inline::C script: 
        use strict;
use warnings;

use Inline C => Config =>
 BUILD_NOISY => 1,
 FORCE_BUILD => 1,

 # Set CC to to path to gcc.exe version 8.3.0
 # This is not the gcc that built perl.
 # Perl was built with gcc-14
 CC => 'C:/sp/_64/sp-5.32.0/c/bin/gcc.exe',

 #LD => 'C:/sp/_64/sp-5.32.0/c/bin/g++.exe',
 #CCFLAGS => '-std=c99 -DWIN32 -DWIN64 -DPERL_TEXTMODE_SCRIPTS -DMULTI
+PLICITY -DPERL_IMPLICIT_SYS ' . '
 #            '-DUSE_PERLIO -D__USE_MINGW_ANSI_STDIO -fwrapv -fno-stri
+ct-aliasing -mms-bitfields',
;

use Inline C => << 'END_OF_C';

void foo() {
  //printf("Hello World !!\n");
}

END_OF_C

foo(); # Does nothing, as expected
print "OK\n";

        [download]
        (I need to double check on what follows.)
        For perls built on Windows from (the same) current blead source using (the same) mingw-w64 built gcc-13 (or 14 or 15) compiler package, there are 2 possible outputs for that script.
        If perl is configured such that $Config{ccflags} begins with "-std=c99" (as is the current default configuration) then the script, upon compiling without issue, immediately outputs a handshake error, and dies.
        But if perl was configured such that the "-std=c99" is omitted from $Config{ccflags} then, upon compiling without issue, the script outputs "OK".

        That seems a bit buggy to me, and I really would like to be able to see for myself that the handshake abort is justified. (Maybe the bug is that the abort does not occur for both cases.)
        If I insert, into foo(), some C code that actually does something, then it all works as intended on the perl that's without the "-std=c99" switch.
        And I've tried various overwritings of LD and CCFLAGS - all of which have made no difference at all to the behaviour).
        I don't understand the reasoning for imposing "-std=c99" on Windows builds of perl (beginning with perl-5.40.0) ... I don't like it ... and I build my perls without it.

        I'll update when (if ever) I get a better picture of what's going on. Will probably never happen unless I knuckle down and work out how to conditionally disable the handshake checks.

        Cheers,
        Rob
[reply]
[d/l]
      But you might have an even easier option - you might be able to monkey patch the XS-generating code right from inside your Inline module! Because again, it's the module that checks, not the interpreter.

      But practically speaking, if I had a handshake error I would be highly interested in getting everything back to working order with perl invoking the correct compiler against the correct headers. You need this baseline to be able to add XS modules from CPAN.

[reply]

In Section Seekers of Perl Wisdom