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

Re: [perl #133440] binaries mismatched again

Thread Previous | Thread Next
Dan Book
August 15, 2018 00:27
Re: [perl #133440] binaries mismatched again
Message ID:
On Tue, Aug 14, 2018 at 8:16 PM <> 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?).
> There seems to be no discussion of changing the mismatched binary
> error message to point to documentation about e.g. updating CPAN
> modules.
> 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,
> Frederick

These are good ideas. The fundamental issue though is that modules you
installed for one major version of Perl must always be installed again for
another, and users don't tend to expect this whether they use local::lib or
not, it will always be a problem if you install modules without using your
package manager in a Perl managed by your package manager.


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