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

Re: [perl #133440] binaries mismatched again

Thread Next
From:
frederik
Date:
August 17, 2018 04:53
Subject:
Re: [perl #133440] binaries mismatched again
Message ID:
17511_1534481601_5B7654BD_17511_346_1_20180817045139.GJ30438@ofb.net
Just wanted to briefly follow this up...

Andreas: "cpan[1]> recompile" worked fine on both my machines. I also
noticed that the second time I run it, it notices nothing needs to be
done, which is great.

Dave: Thanks for the observations. I'm happy to look at the code and
send a patch for a better error message when I have time, which is
probably not going to be within the next month or so. Also I think it
should be worthwhile to investigate a way to get the full module name
in the message, presumably whatever compiles modules (MakeMaker?) can
be changed to provide a CPP macro with the module name, and I think
this could be done in a backwards-compatible manner - whatever that
means.

Dan: I can look at perlbrew et al (it was also recommended off-list),
I'd of course like to see how far I can go with the binaries provided
by my distro.

One problem with my argument that the error message isn't
user-friendly, is that anyone can easily submit a bug for it and get
friendly and helpful replies from the developers, as I have done.
Still, I'm interested in improving things and I hope that I myself or
someone else can find time to work on this in the not-too-distant
future.

Thanks,

Frederick

On Tue, Aug 14, 2018 at 11:47:54PM -0700, (Andreas J. Koenig) via RT wrote:
> >>>>> On Tue, 14 Aug 2018 22:58:52 -0700, frederik@ofb.net said:
> 
>   > But that would argue for version-specific paths (because the different
>   > hosts might have different Perl versions).
> 
> You can sync your .local directory to other machines only if the two
> machines are perfectly in sync with regard to all involved libraries.
> 
> As I read the whole thread here, your problem is recompilation after
> some library upgrade. The shell that comes with CPAN.pm has a commend
> for that, it is called `recompile`. Maye you try that out. Disclaimer: I
> wrote it. Let me know if you have questions about it.
> 
> -- 
> andreas
> 

On Wed, Aug 15, 2018 at 03:35:57AM -0700, Dave Mitchell via RT wrote:
> 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 Next


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