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

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.

Replies are listed 'Best First'.
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, 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.