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

Replies are listed 'Best First'.
Re^3: How do I build perl on Windows such that all "handshake" checks are avoided ? by NERDVANA (Priest) on Oct 13, 2025 at 15:57 UTC
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.	[reply]
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]
Re^5: How do I build perl on Windows such that all "handshake" checks are avoided ? by dave_the_m (Monsignor) on Oct 14, 2025 at 11:28 UTC
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]
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
Re^5: How do I build perl on Windows such that all "handshake" checks are avoided ? by NERDVANA (Priest) on Oct 14, 2025 at 15:10 UTC
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]