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

Re: [perl #133440] binaries mismatched again

Thread Previous | Thread Next
August 15, 2018 00:15
Re: [perl #133440] binaries mismatched again
Message ID:
On Wed, Aug 15, 2018 at 01:19:16AM +0200, Leon Timmermans wrote:
> On Tue, Aug 14, 2018 at 10:41 AM, Dave Mitchell <> wrote:
> > On Mon, Aug 13, 2018 at 11:56:26PM +0200, Leon Timmermans wrote:
> >> I think most people avoid configurations where incompatible perl
> >> builds share the same arch directories. Judging by your @INC my first
> >> guess is that you're reusing your old perl's local::lib directories,
> >> which would indeed blow up in your face.
> >
> > From a quick perusal of local::lib's documentation, it appears that
> > it doesn't use version-specific paths under the local directory, which
> > on the face of it seems like a design flaw.
> Perl doesn't quite provide enough rope to tie that knot. Or at least
> it doesn't for the common scenario where one has multiple
> (incompatible) perls and at login time one doesn't know yet which to
> use when. The only primitive we provide (PERL5LIB) does "prepend these
> dirs to @INC". I can sort of imagine a tool that does what you
> suggest, but the additional complexity and fragility sound
> uncomfortable.
> It's a real problem, but I don't think it can be solved on the
> local::lib side alone.

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?).

There seems to be no discussion of changing the mismatched binary
error message to point to documentation about e.g. updating CPAN

If the default setup were fixed so that version-specific paths were
used for local modules, 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 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)

Hope these suggestions aren't too annoying,


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About