I have seen many posts relating to this type of issue but no canonical way to fix it properly.
Since updating to F23 (from F22) using dnf last night, many/all PERL programs are broken and give errors such as:
fetch_modules: error loading required module Compress/Zlib.pm: Can't load '/usr/local/lib64/perl5/auto/Compress/Raw/Zlib/Zlib.so' for module Compress::Raw::Zlib: libperl.so.5.20: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 193. at /usr/local/share/perl5/Compress/Zlib.pm line 11. Compilation failed in require at /usr/local/share/perl5/Compress/Zlib.pm line 11. BEGIN failed--compilation aborted at /usr/local/share/perl5/Compress/Zlib.pm line 11. Compilation failed in require at /usr/sbin/amavisd line 210. /usr/bin/perl: symbol lookup error: /usr/local/lib64/perl5/auto/MIME/Base64/Base64.so: undefined symbol: Perl_xs_version_bootcheck
or
-- /usr/bin/perl: symbol lookup error: /usr/local/lib64/perl5/auto/Unix/Syslog/Syslog.so: undefined symbol: Perl_xs_version_bootcheck
I understand from other posts that this is probably caused by my having two PERL installations but:
a. I have no idea why there are two PERLs b. I can find no instructions on how to remove one version and (hopefully) fix this issue.
(In the meantime, I cannot run amavisd so am inundated with spam.)
TIA, Stephen
On 09/15/2016 06:04 PM, Stephen Davies wrote:
-- /usr/bin/perl: symbol lookup error: /usr/local/lib64/perl5/auto/Unix/Syslog/Syslog.so: undefined symbol: Perl_xs_version_bootcheck
I understand from other posts that this is probably caused by my having two PERL installations but:
a. I have no idea why there are two PERLs b. I can find no instructions on how to remove one version and (hopefully) fix this issue.
Did you or some program you installed use cpan to install some modules? That's what it looks like. Either remove /usr/local/lib64/perl5 or rename it and see if that fixes your problem.
On 16/09/16 15:32, Samuel Sieb wrote:
On 09/15/2016 06:04 PM, Stephen Davies wrote:
-- /usr/bin/perl: symbol lookup error: /usr/local/lib64/perl5/auto/Unix/Syslog/Syslog.so: undefined symbol: Perl_xs_version_bootcheck
I understand from other posts that this is probably caused by my having two PERL installations but:
a. I have no idea why there are two PERLs b. I can find no instructions on how to remove one version and (hopefully) fix this issue.
Did you or some program you installed use cpan to install some modules? That's what it looks like. Either remove /usr/local/lib64/perl5 or rename it and see if that fixes your problem. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
When a similar thing happened after the F22, I did load/reload some modules via CPAN and that fixed that.
I have since discovered that modules can be installed using dnf (though this is pretty well disguised) and tried that just now.
A combination of that and renaming .so files in the /usr/local/ tree seems to haver fixed the immediate issue but leaves the potential for it to happen again next time.
I take it from your comment that CPAN puts things into /usr/local. Can I just blow away all things PERL in /usr/local and then install any modules that go missing using dnf?
Cheers and thanks, Stephen
On 09/16/2016 12:10 AM, Stephen Davies wrote:
I take it from your comment that CPAN puts things into /usr/local.
Yes.
Can I just blow away all things PERL in /usr/local and then install any modules that go missing using dnf?
Assuming the module is packaged, you can do, for example: dnf install 'perl(Unix::Syslog)' If the module is not packaged, you can use 'cpanspec' to generate rpms that you can install. I used that extensively for a library system I installed. Some of the spec files I had to edit a bit before they would work and you have to package the dependencies first, but I managed to package all the requirements successfully.
-
Samuel Sieb -
Stephen Davies