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 | [reply] |
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] |
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] |