develooper Front page | perl.perl5.porters | Postings from August 2018

Re: [perl #133440] binaries mismatched again

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
August 15, 2018 10:35
Subject:
Re: [perl #133440] binaries mismatched again
Message ID:
26837_1534329350_5B740205_26837_252_1_20180815103536.GQ2798@iabyn.com
On Tue, Aug 14, 2018 at 05:14:41PM -0700, frederik@ofb.net wrote:
> Thanks for the discussion. I don't have two different versions of Perl
> installed, just one version from my distribution Arch, which gets
> updated occasionally.
> 
> I'm not sure where this is headed but I just wanted us to keep in mind
> what it looks like for a new user who is doing the standard (?) thing
> of updating Perl via his distribution packaging system, while having
> CPAN modules installed locally (e.g. in his home directory, is this
> not typical?).

The more typical approach is to have a personal perl installation separate
from the system's one: this would contain both the perl binary plus any
additional modules you have installed. That way you have complete control
over what gets upgraded and when. Using the system perl in combination with
privately built/installed modules puts you at the mercy of whatever your
OS's update/upgrade procedures do to the system perl.

> If the default setup were fixed so that version-specific paths were
> used for local modules,

Note that the default behaviour for perl *is* always to install in
version-specific directories. The behaviour you are seeing is that of a
third-party module, local::lib, which is not bundled with perl, and which
we (p5p) have no control over. (Although elsewhere in this thread it
appears that MakeMaker etc may be to blame too.)

> then what would our user experience consist of
> - user installs CPAN modules to make his scripts work, then a year
> later he upgrades his distribution to a new version of Perl and his
> scripts stop working with "Can't locate XXX.pm in @INC"? I guess that
> is better than the error message I saw, because then the user at least
> has a module name to start with, but I think it would be preferable to
> have an error that somehow ultimately leads (e.g. via a reference to a
> man page) to instructions on upgrading locally-installed CPAN modules.
> 
> To make this concrete, what if you could change the error:
> 
>     Zlib.c: loadable library and perl binaries are mismatched (got handshake key
> 0xde00080, needed 0xce00080)
> 
> 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
> mention cpanm or cpan tools, I wonder if those should be there too)

Some observations.

As I pointed out earlier, I'm not sure that it will be possible (or at
least easy) to display the module name as part of the error message.

I'm very much in favour of removing the 'handshake' part of the message,
and replacing it with something informative and useful - i.e. to actually
decode the hex values and explain what was mismatched.

I'm also not opposed to the error message referring to a man page;
although note that if your perl installation is borked due to version
mismatches, then it's possible that the tool you use for viewing man pages
(such as perldoc) also wont work!

It may be overkill to have a complete new man page - perhaps just an extra
section in an existing document instead?

It will be quite difficult to write such a perlmodupgrade man page. Bear
in mind that the error message you got refers to any sort of mismatch
between the perl binary you are executing, and an XS module which that perl
is trying to load. Your particular scenario is just one of many, and
reinstalling the offending module isn't always the correct solution.  Such
a manual page would have to explain many possible scenarios, including
interactions with third-party solutions such as OS packages, perlbrew,
local::lib etc.

Personally I don't feel I have the expertise to write all of such a
document.

-- 
Any [programming] language that doesn't occasionally surprise the
novice will pay for it by continually surprising the expert.
   -- Larry Wall

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About