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

Re: [perl #133587] toolchain possibilities for avoiding "binariesmismatched" error

Thread Previous | Thread Next
Andy Dougherty
October 15, 2018 19:06
Re: [perl #133587] toolchain possibilities for avoiding "binariesmismatched" error
Message ID:
On Sat, Oct 13, 2018 at 12:15:09PM -0700,  (via RT) wrote:
> # New Ticket Created by   
> # Please include the string:  [perl #133587]
> # in the subject line of all future correspondence about this issue. 
> # <URL: >

> [Please describe your issue here]
> This is a follow-up to an earlier bug report, which complains about
> the fact that users see an uninformative error message "loadable
> library and perl binaries are mismatched", after a Linux distribution
> upgrade, if they have installed Perl modules locally e.g. using the
> 'cpan' tool.

[Incidentally, this issue is not limited to Linux.  If I recall correctly,
the safety check and corresponding error message were contributed by a
Windows user based on his own experience.]

> These mostly have to do with the toolchain, 'cpan'/'cpanm', and
> probably ExtUtils::MakeMaker and other modules, so I'm submitting a
> new bug report which I hope can focus on the toolchain aspect of this
> problem. 

The central issue is that if you expect to encounter multiple versions of
perl, then version-specific files (typically shared libraries) should be
stored in version-specific directories.  The default built-in directory
hierarchies (privlib, vendorlib, and sitelib) do that.  The core pragma is supposed to make it easy to use additional hierarchies with
similar versioned configurations.

One problem is that if the end user does not have write access to the
standard perl directories, there is no obvious easy tool to create
an appropriate private tree with version-specific subdirectories.
Running ExtUtils::MakeMaker with options such as

    perl Makefile.PL INSTALLDIRS=perl PREFIX=$HOME/perl

is one way to do it, but it depends on how the user wants to organize

On the surface, supporting version-specific directories within local::lib
seems like a reasonable feature request.  I've never used it, however,
so I don't know if that would cause other problems.  It also might
be made easier by a new MakeMaker option (sort of like INSTALL_BASE,
but including versions in the library directories).  That's another
reasonable-looking feature request for the ExtUtils::MakeMaker module.

    Andy Dougherty

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