binaries mismatched again

[p5pRT]

Migrated from rt.perl.org#133440 (status was 'open')

Searchable as RT133440$

[p5pRT]

From frederik@ofb.net

Created by frederik@ofb.net

I was able to find that I already reported this bug, sorry​:

https://rt.perl.org/Public/Bug/Display.html?id=130718

Maybe I have a bad memory, but it came up again and I wrote a new report before I remembered the old one. Here it is​:

Every time I upgrade my system, I run into this problem. But I don't upgrade often enough to remember what the solution is.

The problem is that when running Perl code I see error messages containing the text "loadable library and perl binaries are mismatched".

These messages don't point to a remedy, or even a specific module; instead they give the name of a C source file in a module. Googling is not very helpful.

Looking in my shell history, I see that when I upgrade I should do something like "cpan-outdated --exclude-core -p | cpanm".

However, now this command gives such an error​:

$ cpan-outdated --exclude-core -p
Zlib.c​: loadable library and perl binaries are mismatched (got handshake key 0xde00080, needed 0xce00080)

After using 'locate' to search my filesystem for Zlib.c, I was able to figure out the offending module from the path name, and remove it.

$ cpanm -U Compress​::Raw​::Zlib

This made cpan-outdated work again.

However, I think this is all a bit too complicated for casual users to understand. Where is the "discoverability"...?

Am I an atypical user for having basic stuff like Compress​::Raw​::Zlib installed "locally" (i.e. in my home directory)? (I'm not sure how it got there)

Or maybe everyone who encounters this problem knows what to do with a C file name? Or maybe cpan/cpanm are for experts-only? Or maybe Perl itself is experts-only these days?

I should note that I'm using Arch Linux; is there a better situation on Debian-based distros?

I'm not trying to be facetious, I just have a confusing situation and I don't know why other people are not also finding it as confusing as I do. Maybe there is a simple answer.

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.28.0:

Configured by builduser at Wed Aug  1 10:43:08 CEST 2018.

Summary of my perl5 (revision 5 version 28 subversion 0) configuration:
   
  Platform:
    osname=linux
    osvers=4.17.11-arch1
    archname=x86_64-linux-thread-multi
    uname='linux flo-64s 4.17.11-arch1 #1 smp preempt sun jul 29 10:11:16 utc 2018 x86_64 gnulinux '
    config_args='-des -Dusethreads -Duseshrplib -Doptimize=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -Dprefix=/usr -Dvendorprefix=/usr -Dprivlib=/usr/share/perl5/core_perl -Darchlib=/usr/lib/perl5/5.28/core_perl -Dsitelib=/usr/share/perl5/site_perl -Dsitearch=/usr/lib/perl5/5.28/site_perl -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib/perl5/5.28/vendor_perl -Dscriptdir=/usr/bin/core_perl -Dsitescript=/usr/bin/site_perl -Dvendorscript=/usr/bin/vendor_perl -Dinc_version_list=none -Dman1ext=1perl -Dman3ext=3perl -Dcccdlflags='-fPIC' -Dlddlflags=-shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Dldflags=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='cc'
    ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    optimize='-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt'
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='8.1.1 20180531'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='cc'
    ldflags ='-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/include-fixed /usr/lib /lib/../lib /usr/lib/../lib /lib /lib64 /usr/lib64
    libs=-lpthread -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lpthread -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.27.so
    so=so
    useshrplib=true
    libperl=libperl.so
    gnulibc_version='2.27'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.28/core_perl/CORE'
    cccdlflags='-fPIC'
    lddlflags='-shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -L/usr/local/lib -fstack-protector-strong'



@INC for perl 5.28.0:
    /home/frederik/scripts-misc/perl
    /home/frederik/.local/lib/perl5/x86_64-linux-thread-multi
    /home/frederik/.local/lib/perl5
    /usr/lib/perl5/5.28/site_perl
    /usr/share/perl5/site_perl
    /usr/lib/perl5/5.28/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib/perl5/5.28/core_perl
    /usr/share/perl5/core_perl


Environment for perl 5.28.0:
    HOME=/home/frederik
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/home/frederik/.local/arch/x86_64/lib:/home/frederik/.local/lib:/usr/local/lib
    LOGDIR (unset)
    PATH=/home/frederik/.local/bin:/home/frederik/projects/mailproc:/home/frederik/scripts-misc:/home/frederik/.local/arch/x86_64/bin:/usr/bin/core_perl:/usr/bin/vendor_perl:/usr/bin/site_perl:/usr/local/bin:/usr/local/sbin:/usr/bin
    PERL5LIB=/home/frederik/scripts-misc/perl:/home/frederik/.local/lib/perl5:
    PERL_BADLANG (unset)
    PERL_LOCAL_LIB_ROOT=/home/frederik/.local/:/home/frederik/.local/:/home/frederik/.local/:/home/frederik/.local/
    PERL_MB_OPT=--install_base "/home/frederik/.local/"
    PERL_MM_OPT=INSTALL_BASE=/home/frederik/.local/
    SHELL=/bin/zsh

[p5pRT]

From @doughera88

On Fri, Aug 10, 2018 at 11​:24​:20AM -0700, (via RT) wrote​:

# New Ticket Created by
# Please include the string​: [perl #133440]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133440 >

This is a bug report for perl from frederik@​ofb.net,
generated with the help of perlbug 1.41 running under perl 5.28.0.

-----------------------------------------------------------------
[Please describe your issue here]

I was able to find that I already reported this bug, sorry​:

https://rt.perl.org/Public/Bug/Display.html?id=130718

The problem is that when running Perl code I see error messages containing the text "loadable library and perl binaries are mismatched".

Am I an atypical user for having basic stuff like Compress​::Raw​::Zlib installed "locally" (i.e. in my home directory)? (I'm not sure how it got there)

I'm not trying to be facetious, I just have a confusing situation and I don't know why other people are not also finding it as confusing as I do. Maybe there is a simple answer.

The immediate problem is that you have version-specific stuff stored
in a non-version-specific directory. That is, looking at your @​INC,
you have "locally" installed modules in

/home/frederik/\.local/lib/perl5/x86\_64\-linux\-thread\-multi

Perl's configuration defaults are to store version-specific stuff in
version-specific directories. Lots more details are in the INSTALL file,
under the section "Coexistence with earlier versions of perl 5".

I'm not sure why you have Compress​::Raw​::Zlib installed locally, since
it has been bundled with perl since version 5.9.4. Of course you are
certainly welcome to install different versions than those bundled with
perl, but if you are going to do so, and if you're going to store them in
a non-version-specific directory, you'll need to recompile them when
you upgrade to a new major version. Upgrade time is also a good time
to re-visit the question of whether you want to continue overriding the
standard version with your own local version.

Hope that helps a little,

--
  Andy Dougherty doughera@​lafayette.edu

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From frederik@ofb.net

The immediate problem is that you have version-specific stuff stored
in a non-version-specific directory. That is, looking at your @​INC,
you have "locally" installed modules in

/home/frederik/\.local/lib/perl5/x86\_64\-linux\-thread\-multi

Perl's configuration defaults are to store version-specific stuff in
version-specific directories. Lots more details are in the INSTALL file,
under the section "Coexistence with earlier versions of perl 5".

I'm not sure why you have Compress​::Raw​::Zlib installed locally, since
it has been bundled with perl since version 5.9.4. Of course you are
certainly welcome to install different versions than those bundled with
perl, but if you are going to do so, and if you're going to store them in
a non-version-specific directory, you'll need to recompile them when
you upgrade to a new major version. Upgrade time is also a good time
to re-visit the question of whether you want to continue overriding the
standard version with your own local version.

Hope that helps a little,

Thank you, it does. I already know a bit about the technical reason
for the problem. Perhaps I installed something that depended on
Compress​::Raw​::Zlib over 10 years ago, then that module ended up in a
list of modules that I think I need to run various personal scripts
and this is why I have it installed locally. What's this about INSTALL
and version-specific directories? Did I configure things wrong when I
set up cpanm?

I guess I'm wondering why more people aren't coming to you with
questions about this. And why not change the error message to point to
a manual page which explains what to do. By "discoverability" I meant,
a way for users to understand what they're seeing by reading the
documentation that logically presents itself, for instance, if a
module author says "you can install my module using the cpan tool",
then two years later the user gets this error message, what is he
expected to do next, given lack of omniscience - i.e. only knowing
what he had to know to install cpan, and knowing the text of the error
message.

Reading what you wrote, I downloaded 'perl' and looked at INSTALL, at
all the lines containing 'version.*directory' (I didn't have time to
read all 3000 lines yet), and it didn't really answer my question. But
this is not something I think most users would be expected to do; what
happens is you get Perl from your distro and then you see there is a
module in CPAN but not in the distro, so you install it locally using
cpanm, etc. Then things break.

I would like you to say, "Frederick, here is where you went wrong, you
made a mistake that other users are not making when you did X".
Because that would explain why you haven't been getting other bug
reports about this. Lacking such an explanation, I'm kind of fearful
that the answer is that Perl has just become a tool of an older
generation of power users, many young programmers these days haven't
even heard of it, they use bland corporate languages with fewer
"gotchas"... (I'm only guessing here, because I don't use them
myself...) But maybe that's off-topic.

By the way I think I set up cpanm entirely by adding lines from `perl
-Mlocal​::lib=.local` to my shell profile.

Best wishes,

Frederick

[p5pRT]

From @bulk88

On Fri, 10 Aug 2018 11​:24​:20 -0700, frederik@​ofb.net wrote​:

Maybe I have a bad memory, but it came up again and I wrote a new
report before I remembered the old one. Here it is​:

Every time I upgrade my system, I run into this problem. But I don't
upgrade often enough to remember what the solution is.

The problem is that when running Perl code I see error messages
containing the text "loadable library and perl binaries are
mismatched".

These messages don't point to a remedy, or even a specific module;
instead they give the name of a C source file in a module. Googling is
not very helpful.

https://perldoc.perl.org/perldiag.html#List-form-of-piped-open-not-implemented

%s​: loadable library and perl binaries are mismatched (got handshake key %p, needed %p)
(P) A dynamic loading library .so or .dll was being loaded into the process that was built against a different build of perl than the said library was compiled against. Reinstalling the XS module will likely fix this error.

--
bulk88 ~ bulk88 at hotmail.com

[p5pRT]

From @Leont

On Sat, Aug 11, 2018 at 6​:23 AM, <frederik@​ofb.net> wrote​:

I guess I'm wondering why more people aren't coming to you with
questions about this. And why not change the error message to point to
a manual page which explains what to do. By "discoverability" I meant,
a way for users to understand what they're seeing by reading the
documentation that logically presents itself, for instance, if a
module author says "you can install my module using the cpan tool",
then two years later the user gets this error message, what is he
expected to do next, given lack of omniscience - i.e. only knowing
what he had to know to install cpan, and knowing the text of the error
message.

Reading what you wrote, I downloaded 'perl' and looked at INSTALL, at
all the lines containing 'version.*directory' (I didn't have time to
read all 3000 lines yet), and it didn't really answer my question. But
this is not something I think most users would be expected to do; what
happens is you get Perl from your distro and then you see there is a
module in CPAN but not in the distro, so you install it locally using
cpanm, etc. Then things break.

I would like you to say, "Frederick, here is where you went wrong, you
made a mistake that other users are not making when you did X".
Because that would explain why you haven't been getting other bug
reports about this. Lacking such an explanation, I'm kind of fearful
that the answer is that Perl has just become a tool of an older
generation of power users, many young programmers these days haven't
even heard of it, they use bland corporate languages with fewer
"gotchas"... (I'm only guessing here, because I don't use them
myself...) But maybe that's off-topic.

By the way I think I set up cpanm entirely by adding lines from `perl
-Mlocal​::lib=.local` to my shell profile.

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.

Leon

[p5pRT]

From @iabyn

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.

--
If life gives you lemons, you'll probably develop a citric acid allergy.

[p5pRT]

From @eserte

Dana Tue, 14 Aug 2018 01​:42​:09 -0700, davem reče​:

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.

Interestingly, local​::lib creates version-specific paths on first-time initialization. But I think the problem is that by using ExtUtils​::MakeMaker's INSTALL_BASE no installation to version-specific paths happens, so the design flaw is probably there. (Did not check Module​::Build's --install_base)

[p5pRT]

From @Leont

On Tue, Aug 14, 2018 at 10​:41 AM, Dave Mitchell <davem@​iabyn.com> 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.

Leon

[p5pRT]

From frederik@ofb.net

On Wed, Aug 15, 2018 at 01​:19​:16AM +0200, Leon Timmermans wrote​:

On Tue, Aug 14, 2018 at 10​:41 AM, Dave Mitchell <davem@​iabyn.com> 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
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 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)

Hope these suggestions aren't too annoying,

Frederick

[p5pRT]

From @Grinnz

On Tue, Aug 14, 2018 at 8​:16 PM <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?).

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

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.

-Dan

[p5pRT]

From @eserte

Dana Tue, 14 Aug 2018 16​:19​:54 -0700, LeonT reče​:

On Tue, Aug 14, 2018 at 10​:41 AM, Dave Mitchell <davem@​iabyn.com> 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.

The PERL5LIB mechanism is sufficient here. If set user sets something like

  PERL5LIB=/root/perl5/lib/perl5

then @​INC contains automatically

  /root/perl5/lib/perl5/5.28.0/x86_64-linux-thread-multi
  /root/perl5/lib/perl5/5.28.0
  /root/perl5/lib/perl5/x86_64-linux-thread-multi
  /root/perl5/lib/perl5

so architecture and perl api (version) specific files have their place.

The problem is, as I said, that INSTALL_BASE does not use these version-specific files.

[p5pRT]

From frederik@ofb.net

On Tue, Aug 14, 2018 at 05​:28​:03PM -0700, Dan Book via RT wrote​:

On Tue, Aug 14, 2018 at 8​:16 PM <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?).

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

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)];
  ^~~~~~~~~~~
  PL_top_env
 
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,

Frederick

[p5pRT]

From @andk

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

[p5pRT]

From frederik@ofb.net

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.

That's good advice, although I would say that the main problem for me
is users being faced with an error message that doesn't point to a
clear solution. But maybe that's what Stack Exchange or IRC is for?
And maybe I'm the only one that's confused? Nevertheless one would
hope that the local documentation would be sufficient for something
this basic.

FWIW I tried your 'recompile' and I got a bunch of errors. I'm
attaching the output. I'm rerunning it after "cpanm -U Digest​::SHA"
and it seems to be doing something productive.

The approach I tried earlier, which I think I mentioned, was to run
cpan-outdated, but I guess this is something different - its man page
doesn't say anything about helping you recompile binary modules which
may not have actually changed versions. Your suggestion seems more
promising.

Thank you,

Frederick