in reply to Re^4: 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 ?

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.

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

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