Cwd.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xde00080)

Question

All Perl modules and 'cpan' stopped working after an upgrade of Ubuntu 16.04 LTS to 18.04 LTS. Every time I run my script it leads to the error

threads.c: loadable library and Perl binaries are mismatched (got handshake key 0xdb00080, needed 0xde00080)

when I try to open cpan it shows

Cwd.c: loadable library and Perl binaries are mismatched (got handshake key 0xdb00080, needed 0xde00080)

I had installed "Cwd", "threads" modules in ubuntu 16.04 where Perl version was 5.22.1, whereas in ubuntu 18.04 the Perl version is 5.26.1.

I tried to remove the old version of modules but failed. I deleted content on ~/.cpan folder.

PS: Everything works fine in root user. if I run

sudo su
cpan

works perfectly. But as a normal user, I cant run any perl modules/scripts/cpan.

How do I correct the issue? How can I re-install cpan or cpan modules?

I tried to reinstall Perl which did not help

sudo apt-get --reinstall install perl
sudo apt-get --reinstall install libcwd-guard-perl

I installed cpan minus, cpan plus which gave the same error.

We

run the following to see where perl is picking up the bad libraries from: $ strace perl -e'use threads' 2>&1 | grep threads.so If this shows that its trying to load it from a path containing site_perl/, then that's where you may need to manually delete things. As to why it works for root by not a normal user, you many have an environment variable like PERL5LIB set. Try running both which perl perl -le'print for @INC' as both root and non-root, and see whether there are any differences. – Drainpipe

Thanks, @DaveMitchell Perl libraries used by root and the normal user was different, I manually deleted all the libraries which user was taking from. when I create a new user on the pc everything works fine. removing library path worked fine for me. thanks again. – We

Answer 1

For solve problem next links can be used:

https://dev.to/foursixnine/about-perl-and-mismatched-binaries-346l https://metacpan.org/pod/release/DBOOK/App-MigrateModules-0.002/script/perl-migrate-modules

Or in commands: (Replace to your perl5 folder, in my case it was ~/perl5)

 mv <perl5> perl5_old
 cpan
 cpan App::MigrateModules
 perl-migrate-modules --from perl5_old /usr/bin/perl

Where perl5 your perl folder, usually in path exists in ENV variable PERL5LIB.

Thane

Don't be alarmed by passing /usr/bin/perl as the destination of perl-migrate-modules. As long as you have the local::lib environment variables configured, it'll make a new ~/perl5 directory (or whatever you have it set to) and migrate the modules into that folder. – Supertonic

This works, however it should be cpan install App::MigrateModules – Trump

No, it should NOT be cpan install. There is no such command and that's not how cpan works anyway. When it sees install as the first argument it just ignores it. The use in the answer is correct. – Civilly

Answer 2

I solved this issue by following https://github.com/Perl/perl5/issues/15861

I ran the command perl -MCPAN -e 'recompile()'

It recompile all the module, at last it worked.

Untutored

Answer 3

I've also encountered this issue while running a Bioinformatics tool "BRAKER3" via Singularity container.

Most of the answers pointing to the clash between the Perl installed by Root and Perl Library installed by user.

Without Root access, I solved this problem by deleting all environment variables of Perl Library install by user (me) such as $PERL5LIB and adding export PERL5LIB="/usr/lib/perl5:/usr/local/lib/perl5" to my script as well to literally use the Perl things building by Root.

Chalky