Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

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

by c01362 (Initiate)
on Dec 20, 2019 at 18:45 UTC ( #11110449=perlquestion: print w/replies, xml ) Need Help??

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/' for module aarch4p: /home/test/lib/ wrong ELF class: ELFCLASS64 at /usr/lib/perl5/5.8.5/i386-linux-thread-multi/ 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 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 (Chancellor) 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.

      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, 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/ => (0x00007ffc58b57000) => not found => not found => not found => not found => /lib64/ (0x00007fd13bcb6000)
      /lib64/ (0x000055e49d9fc000)

      Version information:
      /home/test/lib/ (GLIBC_2.4) => /lib64/ (GLIBC_2.2.5) => /lib64/
      /lib64/ (GLIBC_PRIVATE) => /lib64/ (GLIBC_2.3) => /lib64/

      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/, 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.
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?


      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.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://11110449]
Approved by haukex
Front-paged by marto
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (3)
As of 2021-10-28 09:24 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (96 votes). Check out past polls.