binaries mismatched again #16654
Comments
From frederik@ofb.netCreated by frederik@ofb.netI was able to find that I already reported this bug, sorry: https://rt.perl.org/Public/Bug/Display.html?id=130718 Maybe I have a bad memory, but it came up again and I wrote a new report before I remembered the old one. Here it is: Every time I upgrade my system, I run into this problem. But I don't upgrade often enough to remember what the solution is. The problem is that when running Perl code I see error messages containing the text "loadable library and perl binaries are mismatched". These messages don't point to a remedy, or even a specific module; instead they give the name of a C source file in a module. Googling is not very helpful. Looking in my shell history, I see that when I upgrade I should do something like "cpan-outdated --exclude-core -p | cpanm". However, now this command gives such an error: $ cpan-outdated --exclude-core -p After using 'locate' to search my filesystem for Zlib.c, I was able to figure out the offending module from the path name, and remove it. $ cpanm -U Compress::Raw::Zlib This made cpan-outdated work again. However, I think this is all a bit too complicated for casual users to understand. Where is the "discoverability"...? Am I an atypical user for having basic stuff like Compress::Raw::Zlib installed "locally" (i.e. in my home directory)? (I'm not sure how it got there) Or maybe everyone who encounters this problem knows what to do with a C file name? Or maybe cpan/cpanm are for experts-only? Or maybe Perl itself is experts-only these days? I should note that I'm using Arch Linux; is there a better situation on Debian-based distros? I'm not trying to be facetious, I just have a confusing situation and I don't know why other people are not also finding it as confusing as I do. Maybe there is a simple answer. Perl Info |
From @doughera88On Fri, Aug 10, 2018 at 11:24:20AM -0700, (via RT) wrote:
The immediate problem is that you have version-specific stuff stored
Perl's configuration defaults are to store version-specific stuff in I'm not sure why you have Compress::Raw::Zlib installed locally, since Hope that helps a little, -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From frederik@ofb.net
Thank you, it does. I already know a bit about the technical reason I guess I'm wondering why more people aren't coming to you with Reading what you wrote, I downloaded 'perl' and looked at INSTALL, at I would like you to say, "Frederick, here is where you went wrong, you By the way I think I set up cpanm entirely by adding lines from `perl Best wishes, Frederick |
From @bulk88On Fri, 10 Aug 2018 11:24:20 -0700, frederik@ofb.net wrote:
https://perldoc.perl.org/perldiag.html#List-form-of-piped-open-not-implemented %s: loadable library and perl binaries are mismatched (got handshake key %p, needed %p) -- |
From @LeontOn Sat, Aug 11, 2018 at 6:23 AM, <frederik@ofb.net> wrote:
I think most people avoid configurations where incompatible perl Leon |
From @iabynOn Mon, Aug 13, 2018 at 11:56:26PM +0200, Leon Timmermans wrote:
From a quick perusal of local::lib's documentation, it appears that -- |
From @eserteDana Tue, 14 Aug 2018 01:42:09 -0700, davem reče:
Interestingly, local::lib creates version-specific paths on first-time initialization. But I think the problem is that by using ExtUtils::MakeMaker's INSTALL_BASE no installation to version-specific paths happens, so the design flaw is probably there. (Did not check Module::Build's --install_base) |
From @LeontOn Tue, Aug 14, 2018 at 10:41 AM, Dave Mitchell <davem@iabyn.com> wrote:
Perl doesn't quite provide enough rope to tie that knot. Or at least It's a real problem, but I don't think it can be solved on the Leon |
From frederik@ofb.netOn Wed, Aug 15, 2018 at 01:19:16AM +0200, Leon Timmermans wrote:
Thanks for the discussion. I don't have two different versions of Perl I'm not sure where this is headed but I just wanted us to keep in mind There seems to be no discussion of changing the mismatched binary If the default setup were fixed so that version-specific paths were To make this concrete, what if you could change the error: Zlib.c: loadable library and perl binaries are mismatched (got handshake key to say: In Perl module Compress::Raw::Zlib (Zlib.c): loadable library and perl binaries are mismatched (got handshake key 0xde00080, needed 0xce00080). Do you need to recompile this module for a new Perl version? See `man perlmodupgrade`. (Actually, I'm noticing that the "perlmodinstall" manual page doesn't Hope these suggestions aren't too annoying, Frederick |
From @GrinnzOn Tue, Aug 14, 2018 at 8:16 PM <frederik@ofb.net> wrote:
These are good ideas. The fundamental issue though is that modules you -Dan |
From @eserteDana Tue, 14 Aug 2018 16:19:54 -0700, LeonT reče:
The PERL5LIB mechanism is sufficient here. If set user sets something like PERL5LIB=/root/perl5/lib/perl5 then @INC contains automatically /root/perl5/lib/perl5/5.28.0/x86_64-linux-thread-multi so architecture and perl api (version) specific files have their place. The problem is, as I said, that INSTALL_BASE does not use these version-specific files. |
From frederik@ofb.netOn Tue, Aug 14, 2018 at 05:28:03PM -0700, Dan Book via RT wrote:
Thanks. So people who use cpanm tend to have Perl compiled locally? I didn't realize that you can do "cpanm Perl" but it looks like it fails: Perl.xs: At top level: But that would argue for version-specific paths (because the different Thank you, Frederick |
From @andk
> But that would argue for version-specific paths (because the different You can sync your .local directory to other machines only if the two As I read the whole thread here, your problem is recompilation after -- |
From frederik@ofb.netOn Tue, Aug 14, 2018 at 11:47:54PM -0700, (Andreas J. Koenig) via RT wrote:
That's good advice, although I would say that the main problem for me FWIW I tried your 'recompile' and I got a bunch of errors. I'm The approach I tried earlier, which I think I mentioned, was to run Thank you, Frederick |
From frederik@ofb.net |
From @iabynOn Tue, Aug 14, 2018 at 05:14:41PM -0700, frederik@ofb.net wrote:
The more typical approach is to have a personal perl installation separate
Note that the default behaviour for perl *is* always to install in
Some observations. As I pointed out earlier, I'm not sure that it will be possible (or at I'm very much in favour of removing the 'handshake' part of the message, I'm also not opposed to the error message referring to a man page; It may be overkill to have a complete new man page - perhaps just an extra It will be quite difficult to write such a perlmodupgrade man page. Bear Personally I don't feel I have the expertise to write all of such a -- |
From @GrinnzOn Wed, Aug 15, 2018 at 6:36 AM Dave Mitchell <davem@iabyn.com> wrote:
To add to this: typical methods of doing this are Perl::Build, perlbrew, -Dan |
From frederik@ofb.netJust wanted to briefly follow this up... Andreas: "cpan[1]> recompile" worked fine on both my machines. I also Dave: Thanks for the observations. I'm happy to look at the code and Dan: I can look at perlbrew et al (it was also recommended off-list), One problem with my argument that the error message isn't Thanks, Frederick On Tue, Aug 14, 2018 at 11:47:54PM -0700, (Andreas J. Koenig) via RT wrote:
On Wed, Aug 15, 2018 at 03:35:57AM -0700, Dave Mitchell via RT wrote:
|
From @andk
> Just wanted to briefly follow this up... Thanks for letting me know and for sending the report how noisy it was Besides that I have also found the original ticket in which we received -- |
From @karenetheridgeOn Wed, Aug 15, 2018 at 3:35 AM, Dave Mitchell <davem@iabyn.com> wrote:
But the toolchain gang does, and there's a large overlap between that group All local::lib does is set some environment variables, e.g.: $ cd ~; perl -Mlocal::lib=local -ether@cpan.org |
From frederik@ofb.netThanks for your reply. While trying to downgrade my system (debugging $ PERL5LIB= cpanm -U Digest::SHA (after cpan recompile) $ perldoc -l Time::HiRes I don't know if this is a bug or just an annoyance, but it may go a Also, I notice that if I ask 'cpanm' to install a module which is $ perldoc -l DB_File I haven't checked what happens if I use cpanm to install a module I couldn't figure out how to use the 'cpan' tool to remove modules, Also, I see 'cpan -r -T' runs lots of tests, I thought '-T' was to Hope this helps, Frederick On Fri, Aug 17, 2018 at 01:40:52PM -0700, (Andreas J. Koenig) via RT wrote:
|
From @GrinnzOn Sat, Aug 18, 2018 at 11:26 PM <frederik@ofb.net> wrote:
These are dual-life modules; it is expected and often desired to install -Dan |
From frederik@ofb.net
You're saying that these modules are purposefully installed by 'cpan' I guess not everyone expects this, because when I first submitted this Thanks, Frederick |
From @GrinnzOn Tue, Aug 21, 2018 at 7:45 PM <frederik@ofb.net> wrote:
That is correct. His response seemed to account for this possibility but -Dan |
From frederik@ofb.netBy the way I never took the time to thank you for pointing these Thanks! Frederick On Sat, Aug 18, 2018 at 07:55:29PM -0700, Karen Etheridge via RT wrote:
|
From @iabynOn Sat, Aug 18, 2018 at 07:55:14PM -0700, Karen Etheridge wrote:
You quoted one paragraph of mine from a long email, where I had clearly What I said in that paragraph is also completely true - whatever So I'm mildly peeved by your response, and the OP's follow up of "oh at -- |
From frederik@ofb.net
I'm sorry Dave, my reply to Karen was meant to be off-list, but I In any case I wasn't thanking her for taking responsibility, but for I'm attaching some proposed patches for P5P, maybe I have enough I would hope that eventually the full module name can be reported by Thank you, Frederick |
From frederik@ofb.netutil.c.diff--- perl-5.28.0/util.c 2018-05-21 05:29:23.000000000 -0700
+++ /home/frederik/util.c-mod 2018-08-22 09:19:26.797143798 -0700
@@ -5337,7 +5337,8 @@
bad_handshake:/* recycle branch and string from above */
if(got != (void *)HSf_NOCHK)
noperl_die("%s: loadable library and perl binaries are mismatched"
- " (got handshake key %p, needed %p)\n",
+ " (got handshake key %p, needed %p)."
+ " See perldiag(1) (do you need to recompile?)\n",
file, got, need);
}
|
From frederik@ofb.netperldiag.diff--- perl-5.28.0/pod/perldiag.pod 2018-05-21 05:29:23.000000000 -0700
+++ /home/frederik/perldiag-mod 2018-08-22 09:34:08.050699448 -0700
@@ -3365,11 +3365,52 @@
=item %s: loadable library and perl binaries are mismatched (got handshake key %p, needed %p)
-(P) A dynamic loading library C<.so> or C<.dll> was being loaded into the
-process that was built against a different build of perl than the
-said library was compiled against. Reinstalling the XS module will
+(P) A dynamic loading library C<.so> or C<.dll> was being loaded into
+the process that was built against a different build of perl than the
+said library was compiled against. Reinstalling the XS module will
likely fix this error.
+Typically this error occurs after an OS distribution upgrade, in which
+a new Perl version has been installed system-wide, but modules
+installed locally (e.g. in the user's home directory) have not been
+recompiled yet. In this case the problem can be fixed by telling the
+cpan tool to recompile all local modules. For example, on Unix-based
+installations:
+
+ $ PERL5LIB= cpan -r
+
+(the "PERL5LIB=" prefix ensures that cpan doesn't try to use local
+modules which are assumed to be broken in this case). This command
+should be run after every distribution upgrade.
+
+Alternatively, heavy users of modules downloaded from CPAN can install
+a local Perl instance using such tools as Perl::Build, perlbrew, and
+plenv, and use these when running local scripts. This will allow
+locally-installed Perl software to keep working when the system-wide
+Perl is upgraded, by managing two (or more) distinct versions of the
+Perl interpreter in parallel.
+
+To deal with this error in a module-specific way, the location of the
+offending module can be found by searching in your PERL5LIB for a file
+with the same name as is listed in the error message, for example:
+
+ Parser.c: loadable library and perl binaries are mismatched (got handshake key 0xce00080, needed 0xde00080)
+ # Find the DLL, looks like it belongs to the HTML::Parser module
+ $ find .local/lib/perl5 | grep Parser.so
+ .local/lib/perl5/x86_64-linux-thread-multi/auto/HTML/Parser/Parser.so
+ # Check that this is really where the module is
+ $ perldoc -l HTML::Parser
+ ~/.local/lib/perl5/x86_64-linux-thread-multi/HTML/Parser.pm
+ # Notice that the module is also installed system-wide
+ $ PERL5LIB= perldoc -l HTML::Parser
+ /usr/lib/perl5/5.26/vendor_perl/HTML/Parser.pm
+ # Remove the local version of the library (if installed via cpan)
+ $ PERL5LIB= cpanm -U HTML::Parser
+ ...
+ # Download, compile and install the newest version of the library (if
+ # needed)
+ $ PERL5LIB= cpanm HTML::Parser
+
=item Locale '%s' contains (at least) the following characters which
have unexpected meanings: %s The Perl program will use the expected
meanings
|
From frederik@ofb.netHere is an updated version of the documentation patch. I made some After I learned that 'cpan -r' and other installation commands cause The 'cpanm' man page has some promising options for excluding core and $ cpanm --self-contained --exclude-vendor HTTP::Date If anyone can comment on this... I also welcome comments on the patches. Thanks, Frederick |
From @iabynOn Mon, Aug 27, 2018 at 09:26:35AM -0700, frederik@ofb.net wrote:
I'm not seeing anything attached. -- |
From frederik@ofb.netApologies, trying that again... On Tue, Aug 28, 2018 at 12:48:29AM -0700, Dave Mitchell via RT wrote:
|
From frederik@ofb.netperldiag.2.diff--- /home/frederik/pkg-tmp/packages/perl/trunk/src/perl-5.28.0/pod/perldiag.pod 2018-05-21 05:29:23.000000000 -0700
+++ /home/frederik/perldiag-mod 2018-08-27 09:19:20.502177824 -0700
@@ -3370,6 +3370,64 @@
said library was compiled against. Reinstalling the XS module will
likely fix this error.
+Typically this error occurs after an OS distribution upgrade, in which
+a new Perl version has been installed system-wide, but modules
+installed locally (e.g. in the user's home directory) have not been
+recompiled yet. In the common case where the modules have been
+installed using the 'cpan' or 'cpanm' tool, the problem can be fixed
+by telling 'cpan' to recompile all local modules. For example, on
+Unix-based installations:
+
+ $ PERL5LIB= cpan -r
+
+(the "PERL5LIB=" prefix ensures that cpan doesn't try to use local
+modules, which are assumed to be broken in this case). This command
+should be run after every distribution upgrade.
+
+Alternatively, heavy users of locally-compiled modules can install a
+local Perl instance using such tools as Perl::Build, perlbrew, and
+plenv, and use these when running local scripts. This will allow
+locally-installed Perl software to keep working when the system-wide
+Perl is upgraded, by managing two (or more) distinct versions of the
+Perl interpreter in parallel.
+
+Consider using modules packaged by your distribution when possible,
+rather than downloading and compiling them using the 'cpan' tool.
+Unlike locally-compiled modules, these will be automatically upgraded
+when you upgrade your distribution's perl package. For example, rather
+than installing BerkeleyDB or CGI from CPAN, check whether your
+distribution has a package called perl-berkeleydb or perl-cgi, and
+install that package instead.
+
+If you prefer to address this error on a per-module basis, you can
+find the location of the offending module by searching directories in
+your PERL5LIB for a file with the same name as is listed in the error
+message, for example:
+
+ $ some-perl-script
+ Parser.c: loadable library and perl binaries are mismatched ...
+
+ ## Find the DLL, looks like it belongs to the HTML::Parser module
+ $ find .local/lib/perl5 | grep Parser.so
+ .local/lib/perl5/x86_64-linux-thread-multi/auto/HTML/Parser/Parser.so
+
+ ## Check that this is really where the module is
+ $ perldoc -l HTML::Parser
+ ~/.local/lib/perl5/x86_64-linux-thread-multi/HTML/Parser.pm
+
+ ## Notice that the module is also installed system-wide
+ $ PERL5LIB= perldoc -l HTML::Parser
+ /usr/lib/perl5/5.26/vendor_perl/HTML/Parser.pm
+
+ ## Remove the local version of the library (if installed via cpan).
+ ## After this, the system version will be used.
+ $ PERL5LIB= cpanm -U HTML::Parser
+ ...
+
+ ## Download, compile and install the newest version of the library
+ ## (if the system version isn't new enough for you)
+ $ PERL5LIB= cpanm HTML::Parser
+
=item Locale '%s' contains (at least) the following characters which
have unexpected meanings: %s The Perl program will use the expected
meanings
|
From frederik@ofb.netAny comments on the patch? |
From @iabynOn Tue, Aug 28, 2018 at 08:23:57AM -0700, frederik@ofb.net wrote:
I dislike this text (and by extension the whole patch). You are mentioning There are many reasons why a user might get this error, and your case was -- |
From frederik@ofb.netOn Mon, Sep 17, 2018 at 12:24:31PM +0100, Dave Mitchell wrote:
Thanks for the feedback. Do you use Linux From Scratich or something? I guess my patch makes a lot of assumptions about how people would get Another thing which is confusing is that the software, while If it is just that one sentence that's a problem, then it would "Typically this error occurs after a new version of Perl has been Also I don't know the "pod" format, I'm assuming that it would be Thanks, Frederick |
From @xenuOn Mon, 17 Sep 2018, at 13:24, Dave Mitchell wrote:
As someone who spends a lot of time on perl support irc channels, I'd say it's the most |
From @iabynOn Mon, Sep 17, 2018 at 07:15:55AM -0700, frederik@ofb.net wrote:
No, I think the general thrust of the patch is misguided. As I said a lot The particular scenario you encountered seems to me to be relatively rare. 1) You were using the OS's perl installation. Change any of those conditions and you likely wouldn't have seen that Some other ways of getting that error message include: All you can really say about that error message, is that a perl -- |
From frederik@ofb.netHi Dave, I'm looking over the messages in this thread and I see that you said Are you still interested in brainstorming about ways to fix this Thanks, Frederick On Tue, Sep 18, 2018 at 10:43:27AM +0100, Dave Mitchell wrote:
|
From @LeontOn Tue, Sep 18, 2018 at 11:44 AM Dave Mitchell <davem@iabyn.com> wrote:
Yeah, especially the first option is quite easily triggered in my That said, there is one thing about the case Frederik describes that Leon |
|
I will add a note
is the best that can be done for the error message.
Where is How is Maybe, on ELF Linux platforms, you swapped out half the functions calls inside |
-this fatal error is much more common by general users than I (orig author) anticipated when I added this check in 5.21.6/2014. I assumed Unix land never had ABI/SEGVing or upgrade problems previous. I wrote the code for my dev style, and my personal setup as test cases, and test cases with Win32-isms. If other OSes get bad-ABI caught, its a plus, but I thought they wouldn't. -the hexadecimal handshake keys were intended to be a debug tool for core devs hacking on something and for XS authors with very complicated Makefile.PL s. To catch -D CCFLAGS arg dropouts on the way to the final cmd line invocation of the CC. -I say the handshake keys are a terrible UI for general "power users" and non-coder sys admins -the Perl API version strings ARE available, even with mismatched interp struct sizes, and those are much more user friendly to print as a error. It should be obvious that from now on, non-power users can figure out on their own (no community help) that a way to "fix" XS boot handshake is to force "reinstall" the "left side perl" or "right side perl" through the OS Pkg Manager. -after this commit, much more often! but not always, users will see a "Perl API 5.X.Y against 5.X+1.Y is incompatible" fatal message instead of the those Core-dev only undocumented hex handshake keys. Sadly the technical P5P debug info is now gone/lost/hidden if "Perl API 5.X.Y against 5.X+1.Y is incompatible" fatal message executes. -core devs, obv will have v5.X.Y matching v5.X.Y in blead perl, so they will still get the handshake keys hex numbers. Since API strings are same. -Package name will get downgraded to "Foo.c" if interp size is wrong, or 2 libperls in 1 proc happens. But the major improvement is showing left and right side Perl API version info. This commit was specifically written for Perl#16654 but there are dozens or 100s of them Perl#19112
-this fatal error is much more common by general users than I (orig author) anticipated when I added this check in 5.21.6/2014. I assumed Unix land never had ABI/SEGVing or upgrade problems previous. I wrote the code for my dev style, and my personal setup as test cases, and test cases with Win32-isms. If other OSes get bad-ABI caught, its a plus, but I thought they wouldn't. -the hexadecimal handshake keys were intended to be a debug tool for core devs hacking on something and for XS authors with very complicated Makefile.PL s. To catch -D CCFLAGS arg dropouts on the way to the final cmd line invocation of the CC. -I say the handshake keys are a terrible UI for general "power users" and non-coder sys admins -the Perl API version strings ARE available, even with mismatched interp struct sizes, and those are much more user friendly to print as a error. It should be obvious that from now on, non-power users can figure out on their own (no community help) that a way to "fix" XS boot handshake is to force "reinstall" the "left side perl" or "right side perl" through the OS Pkg Manager. -after this commit, much more often! but not always, users will see a "Perl API 5.X.Y against 5.X+1.Y is incompatible" fatal message instead of the those Core-dev only undocumented hex handshake keys. Sadly the technical P5P debug info is now gone/lost/hidden if "Perl API 5.X.Y against 5.X+1.Y is incompatible" fatal message executes. -core devs, obv will have v5.X.Y matching v5.X.Y in blead perl, so they will still get the handshake keys hex numbers. Since API strings are same. -Package name will get downgraded to "Foo.c" if interp size is wrong, or 2 libperls in 1 proc happens. But the major improvement is showing left and right side Perl API version info. This commit was specifically written for Perl#16654 but there are dozens or 100s of them Perl#19112
Example of a call stack showing why |
|
Googling perl binaries mismatch, I'm finding alot of misinfo and unawareness by many linux users, sys admins, and even seasoned Perl devs. More than once, a group of linux users repeatedly delete the Somewhere in perl's docs to fix binaries mismatch the following topics need to be said, and the misinfo corrected.
I'm not joking. From looking at various perl programming references, and P5P's official POD docs. It accidentally is a trade secret, that the Perl interpreter, is written in C. I'm not joking. I gave away my Camel book long ago, but O'Reilly Perl Cookbook 2nd Ed.
The first very subtle evidence Perl 5 is written in C, is page 294 of the book. First real evidence Perl 5 is probably written in a memory unsafe language is ~ page 490 with So, basically the average demographic of someone trying to fix this, is a well experienced HTML/JS or Java dev, that even if they know exactly what a From my whole memory, there is only ONE sentence on ONE medium blog, that documents, the fact, that Perl 5, does not have a native code JIT assembler inside of it. Every perl dev knows P5 doesnt have a native code JIT inside of it, only by omission. P5P and Larry never documented that design trait. |
-this fatal error is much more common by general users than I (orig author) anticipated when I added this check in 5.21.6/2014. I assumed Unix land never had ABI/SEGVing or upgrade problems previous. I wrote the code for my dev style, and my personal setup as test cases, and test cases with Win32-isms. If other OSes get bad-ABI caught, its a plus, but I thought they wouldn't. -the hexadecimal handshake keys were intended to be a debug tool for core devs hacking on something and for XS authors with very complicated Makefile.PL s. To catch -D CCFLAGS arg dropouts on the way to the final cmd line invocation of the CC. -I say the handshake keys are a terrible UI for general "power users" and non-coder sys admins -the Perl API version strings ARE available, even with mismatched interp struct sizes, and those are much more user friendly to print as a error. It should be obvious that from now on, non-power users can figure out on their own (no community help) that a way to "fix" XS boot handshake is to force "reinstall" the "left side perl" or "right side perl" through the OS Pkg Manager. -after this commit, much more often! but not always, users will see a "Perl API 5.X.Y against 5.X+1.Y is incompatible" fatal message instead of the those Core-dev only undocumented hex handshake keys. Sadly the technical P5P debug info is now gone/lost/hidden if "Perl API 5.X.Y against 5.X+1.Y is incompatible" fatal message executes. -core devs, obv will have v5.X.Y matching v5.X.Y in blead perl, so they will still get the handshake keys hex numbers. Since API strings are same. -Package name will get downgraded to "Foo.c" if interp size is wrong, or 2 libperls in 1 proc happens. But the major improvement is showing left and right side Perl API version info. -The POD text is very wordy and detailed, since it has been observed over time, some Perl users, do not know Perl's backend implementation is written in the ISO C language. Or other Perl users on various internet forums or social media, do not know what the term XS code is. While they can sucessful write and debug private personal Perl 5 code, they only read the POD of CPAN modules and only use public documented APIs of CPAN modules, and rarely or never look at "private source" of CPAN modules. Therefore this group of users truly do not know MANY MANY p5p core modules and CPAN modules, make call outs to another language (C), and are unable to troubleshoot a .so file on their filing system is responsible for the error. Since they do not know about XS code concept, their troubleshooting goes very wrong as they keeping looking and keep incorrect diagnosing the problem to ASCII text somewhere in the Perl ecosystem. Either Perl source code, they wrote, or CPAN Perl source code, or a CSV, YAML or JSON file related to Perl. Make it clear, that some "Perl 5 modules" written in ASCII text in Perl 5 lang, depend on "foreign" C code and "foreign" .so/.dll files at runtime. First time Perl coders, can mistakenly assume the Perl 5 interpreter has JIT and self bootstraps to OS binaries from only Perl 5 source like Google Chrome V8 and Raku. So they guess, as first time users, Perl 5 also does it and has no dependency on legacy technologies like C or C++. This commit was specifically written for Perl#16654 but there are dozens or 100s of them Perl#19112
|
As part of this, I'm trying to make a top-level article in /r/perl to fix the googling issue. I'll aggressively edit that for correctness as search ability. I'd like to make this something we can all point to when this comes up, but also something organic search results will prioritize (since it's reddit). If I can explain things better or fix an error, leave a comment in the reddit thread. I will note that Learning Perl and Programming Perl mention C pretty quickly. I wouldn't expect the Cookbook to be the one to have to say that. C is all over the perl docs, and there's the "Internals and C Language Interface" section heading in the main perl docs page. But, people don't read so it doesn't really matter how much we document it. |
-this fatal error is much more common by general users than I (orig author) anticipated when I added this check in 5.21.6/2014. I assumed Unix land never had ABI/SEGVing or upgrade problems previous. I wrote the code for my dev style, and my personal setup as test cases, and test cases with Win32-isms. If other OSes get bad-ABI caught, its a plus, but I thought they wouldn't. -the hexadecimal handshake keys were intended to be a debug tool for core devs hacking on something and for XS authors with very complicated Makefile.PL s. To catch -D CCFLAGS arg dropouts on the way to the final cmd line invocation of the CC. -I say the handshake keys are a terrible UI for general "power users" and non-coder sys admins -the Perl API version strings ARE available, even with mismatched interp struct sizes, and those are much more user friendly to print as a error. It should be obvious that from now on, non-power users can figure out on their own (no community help) that a way to "fix" XS boot handshake is to force "reinstall" the "left side perl" or "right side perl" through the OS Pkg Manager. -after this commit, much more often! but not always, users will see a "Perl API 5.X.Y against 5.X+1.Y is incompatible" fatal message instead of the those Core-dev only undocumented hex handshake keys. Sadly the technical P5P debug info is now gone/lost/hidden if "Perl API 5.X.Y against 5.X+1.Y is incompatible" fatal message executes. -core devs, obv will have v5.X.Y matching v5.X.Y in blead perl, so they will still get the handshake keys hex numbers. Since API strings are same. -Package name will get downgraded to "Foo.c" if interp size is wrong, or 2 libperls in 1 proc happens. But the major improvement is showing left and right side Perl API version info. -The POD text is very wordy and detailed, since it has been observed over time, some Perl users, do not know Perl's backend implementation is written in the ISO C language. Or other Perl users on various internet forums or social media, do not know what the term XS code is. While they can sucessful write and debug private personal Perl 5 code, they only read the POD of CPAN modules and only use public documented APIs of CPAN modules, and rarely or never look at "private source" of CPAN modules. Therefore this group of users truly do not know MANY MANY p5p core modules and CPAN modules, make call outs to another language (C), and are unable to troubleshoot a .so file on their filing system is responsible for the error. Since they do not know about XS code concept, their troubleshooting goes very wrong as they keeping looking and keep incorrect diagnosing the problem to ASCII text somewhere in the Perl ecosystem. Either Perl source code, they wrote, or CPAN Perl source code, or a CSV, YAML or JSON file related to Perl. Make it clear, that some "Perl 5 modules" written in ASCII text in Perl 5 lang, depend on "foreign" C code and "foreign" .so/.dll files at runtime. First time Perl coders, can mistakenly assume the Perl 5 interpreter has JIT and self bootstraps to OS binaries from only Perl 5 source like Google Chrome V8 and Raku. So they guess, as first time users, Perl 5 also does it and has no dependency on legacy technologies like C or C++. This commit was specifically written for Perl#16654 but there are dozens or 100s of them Perl#19112
Migrated from rt.perl.org#133440 (status was 'open')
Searchable as RT133440$
The text was updated successfully, but these errors were encountered: