Description of problem: If I try to run perltidy (from package perltidy-20180220-1.fc28.noarch) or if I try to run any perl program that does "use PDF::API2" (which I got from CPAN), I get this diagnostic: Can't load '/usr/local/lib64/perl5/auto/Encode/Encode.so' for module Encode: libperl.so.5.24: cannot open shared object file: No such file or directory at /usr/share/perl5/XSLoader.pm line 96. I don't have libperl.so.5.24 because my Perl is version 5.26.2, not version 5.24. But XSLoader.pm is provided by package perl-libs, for which I also have 5.26.2. Version-Release number of selected component (if applicable): See above. I don't know if other packages are involved. How reproducible: Type "perltidy <foo" at the shell prompt, where "foo" is a Perl program. Steps to Reproduce: 1. 2. 3. Actual results: Can't load '/usr/local/lib64/perl5/auto/Encode/Encode.so' for module Encode: libperl.so.5.24: cannot open shared object file: No such file or directory at /usr/share/perl5/XSLoader.pm line 96. Expected results: Produces a nicely formatted copy of "foo" on stdout. Additional info: A Perl program that uses PDF::API2 fails in the same way.
I forgot to mention, I was using Fedora 27 until yesterday and this bug was present there too. I first noticed it in February but did not file a bug report at that time.
Your problem is /usr/local/lib64/perl5/auto/Encode/Encode.so file. This is your local installation for Encode module from CPAN made when have installed Fedora 26 with Perl 5.24. Thus at file was built against libperl.so.5.24 library. More information find here: https://bugzilla.redhat.com/show_bug.cgi?id=1526063#c3 *** This bug has been marked as a duplicate of bug 1526063 ***
Thanks. I must have obtained "Encode" from CPAN at some time in the past and then forgotten doing it, so I thought it came from an rpm. I've now reinstalled "Encode" from CPAN and that fixed it.
(In reply to Mark Brader from comment #3) > Thanks. I must have obtained "Encode" from CPAN at some time in the past > and then forgotten doing it, so I thought it came from an rpm. You can use "rpm -qf /usr/local/lib64/perl5/auto/Encode/Encode.so" to check whether the file is delivered by an RPM package. > I've now reinstalled "Encode" from CPAN and that fixed it. This will break again when you upgrade to Fedora with Perl 5.28. I would recommend you to uninstall Encode from CPAN. Fedora delivers Encode in perl-Encode and perl-Encode-devel RPM packages. You can use "dnf install perl(Encode)" to get Encode Perl module installed from an RPM.
(In reply to Petr Pisar, comment #4) >> Thanks. I must have obtained "Encode" from CPAN at some time in the past >> and then forgotten doing it, so I thought it came from an rpm. > You can use "rpm -qf /usr/local/lib64/perl5/auto/Encode/Encode.so" to check > whether the file is delivered by an RPM package. In fact I did that, I just didn't believe the result. >> I've now reinstalled "Encode" from CPAN and that fixed it. > This will break again when you upgrade to Fedora with Perl 5.28. I know, but I figured "now I know how to fix it". > I would > recommend you to uninstall Encode from CPAN. Fedora delivers Encode in perl- > Encode and perl-Encode-devel RPM packages. In fact it turns out that I had perl-Encode installed already (presumably not something I did deliberately), but it installs things into /usr/lib64/perl5/vendor_perl rather than /usr/local/lib64/perl5. Presumably Perl was accessing the latter directory first and not looking further, so it didn't pick up the working version. > You can use "dnf install perl(Encode)" to get Encode Perl module > installed from an RPM. Interesting, I did not know about that syntax. (And I'm annoyed to find that it works for "dnf install" but not for "dnf search".) Thanks for your help.
(In reply to Mark Brader from comment #5) > In fact it turns out that I had perl-Encode installed already (presumably > not something I did deliberately), but it installs things into > /usr/lib64/perl5/vendor_perl rather than /usr/local/lib64/perl5. > Presumably Perl was accessing the latter directory first and not looking > further, so it didn't pick up the working version. > This is how Perl works. Perl has a built-in list of paths to search for installed modules (see the last @INC blokc in "perl -V" output) and the order is important. The first match is used. It's designed so that users can override distribution modules (/usr/lib64/perl5/vendor_perl) by installing manullay from CPAN (/usr/local/lib64/perl5). > > You can use "dnf install perl(Encode)" to get Encode Perl module > > installed from an RPM. > > Interesting, I did not know about that syntax. (And I'm annoyed to > find that it works for "dnf install" but not for "dnf search".) > "dnf search" looks up for RPM package names only. The perl() strings are a RPM package metadata called Provides and they can be searched with "dnf whatprovides 'perl(Encode)'" or "dnf repoquery --whatprovides 'perl(Encode)'".