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

Re: [perl #133440] binaries mismatched again

Thread Previous | Thread Next
August 15, 2018 05:59
Re: [perl #133440] binaries mismatched again
Message ID:
On Tue, Aug 14, 2018 at 05:28:03PM -0700, Dan Book via RT wrote:
> 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.

Thanks. So people who use cpanm tend to have Perl compiled locally?
I'm still trying to figure out the common use case.

I didn't realize that you can do "cpanm Perl" but it looks like it fails:

    Perl.xs: At top level:
    Perl.xs:33:27: error: ‘PL_tokenbuf’ undeclared here (not in a function); did you mean ‘PL_top_env’?
         char ptokenbuf[sizeof(PL_tokenbuf)];
I wonder how much space this ends up taking up were it to succeed. I
think the idea with having modules installed in my home directory is
that other scripts in my home directory can then depend on them, and I
can sync the scripts between different hosts along with my shell
config and so on.

But that would argue for version-specific paths (because the different
hosts might have different Perl versions).

Thank you,


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