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. | [reply] |
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.)
| [reply] |
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] |
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. | [reply] [d/l] [select] |