Vendor program can't load *.so file after OS patching

c01362 has asked for the wisdom of the Perl Monks concerning the following question:

Hello all.
We have a lab application running on RHEL 6 with poor vendor support that started having issues after applying the latest OS patches.

Here's the error encountered when we try to start the app:
Can't load '/home/test/lib/aarch4p.so' for module aarch4p: /home/test/lib/aarch4p.so: wrong ELF class: ELFCLASS64 at /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DynaLoader.pm line 230. at /home/test/bin/startup line 54

Line 54 of the startup script is simply "use aarch4p;"
And line 230 (and 231) of the DynaLoader.pm file is:
my $libref = dl_load_file($file, $module->dl_load_flags) or
croak("Can't load '$file' for module $module: ".dl_error());

I'm certain some shared object/library/file updated as part of the OS patching is the source of the problem but I'm not sure where to begin looking.
I'm not a Perl expert by any stretch of the imagination so if you are gracious enough to reply, please be as explicit as possible.
I realize I haven't provided much information here but any suggestions on where to look for the source of the issue would really be appreciated.
Thanks all.

Comment on Vendor program can't load *.so file after OS patching

Replies are listed 'Best First'.
Re: Vendor program can't load *.so file after OS patching by Fletch (Bishop) on Dec 20, 2019 at 19:04 UTC
That error looks to be saying that you're trying to load a 64-bit ELF shared object into a 32-bit perl binary (you can tell by the `i386-linux-thread-multi` bit of the path to `DynaLoader`). My guess is that your OS upgrade didn't downgrade the OS' perl to 32-bit; presuming this `aarch4p` is something you've built locally prossibly you were using another (possibly locally compiled) 64-bit perl somewhere else that is (due to your OS patching, the phase of the moon, yadda yadda yadda) no longer being found on your `PATH`. So either figure out where that other 64-bit perl went and point your `PATH` to find it, or recompile/reinstall the `aarch4p` module with the 32-bit perl you're trying to use now. Update: Additionally this is why you pretty much never want to use the OS' perl install for your application because you're at the vendor's whim WRT upgrades / downgrades / sidegrades. Always compile your own "application" copy of perl somewhere separate (perlbrew is useful for this) and point things at that rather than `/usr/bin/perl`. The cake is a lie. The cake is a lie. The cake is a lie.	[reply] [d/l] [select]
Re^2: Vendor program can't load *.so file after OS patching by c01362 (Initiate) on Dec 20, 2019 at 21:46 UTC
Hello and thanks for the feedback. Perl wasn't updated as part of the OS patching. I'm told the vendor has their own copy of perl bundled within the app that it uses as shown here. # /home/test/perl5/perls/perl-5.22.0/bin/perl -v This is perl 5, version 22, subversion 0 (v5.22.0) built for x86_64-linux-thread-multi (with 1 registered patch, see perl -V for more detail) Copyright 1987-2015, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. I did check the libraries used by the shared object mentioned in the error as listed here. # ldd -v /home/test/lib/aarch4p.so linux-vdso.so.1 => (0x00007ffc58b57000) libatech.so => not found libaarch.so => not found libpwlab.so => not found libsdb.so => not found libc.so.6 => /lib64/libc.so.6 (0x00007fd13bcb6000) /lib64/ld-linux-x86-64.so.2 (0x000055e49d9fc000) Version information: /home/test/lib/aarch4p.so: libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 /lib64/libc.so.6: ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 Those are part of the glibc-2.12-1.212.el6_10.3.x86_64 package that was updated as part of the OS patching. I beginning to think the /home/test/lib/aarch4p.so, or another app specific shared object, is having issues with the latest glibc package. Not sure what else to look at. I'm guessing we'll have to follow up with the vendor since still they technically support this app. Thanks again for replying and let me know if you have any other thoughts on it.	[reply]
Re: Vendor program can't load *.so file after OS patching by shadowsong (Pilgrim) on Dec 21, 2019 at 00:40 UTC
Hi c01362 How are you launching the app? What user are you launching the app as? What's the output of `which perl` when it's run as said user? Cheers, Shadowsong	[reply] [d/l]
Re^2: Vendor program can't load *.so file after OS patching by c01362 (Initiate) on Dec 22, 2019 at 20:53 UTC
Hello again. The first person who responded to this thread pointed me in the right direction. For some odd reason the application was using the OS perl instead of the perl bundled within the app. The OS perl was a link to a 32-bit version of perl, that's why we got reference to i386 and ELFCLASS error. We fixed that so the link is now to a 64-bit version of perl. So now whether the app version or OS version is used, the application should start up fine. We're still not sure why the app startup chose the OS version over the app version of perl. The app version is listed first in the PATH environment variable. Anyway, we have the perl issue figured out and I appreciate the assistance. Thanks all.	[reply]