Re: Running a perl 5.8.6 CentOS 6-compiled app on a CentOS 8 platform

   -bash: /usr/local/ese/bin/ese_configurator.pl: /usr/local/ese/bin/p
+erl: bad interpreter: No such file or directory

Could you make sure that the interpreter does exist and works by running:

/usr/local/ese/bin/perl

. Is this a link and what's its endpoint, does it run at all?

and also

ldd /usr/local/ese/perl/bin/perl5.8.6
        not a dynamic executable>

what's the relation of the above to the aforementioned interpreter?

Using Perlbrew to install an older Perl version, while your system uses its own, is the way to go. But you need to be able to use it without interference from system-installed Perl.

Perl XS modules need recompilation when system libraries that they depend on change. I guess even legacy Perls need their XS modules recompiled when OS changes libraries.

How about creating a new user. In this user's bash script (login script etc.) you specify to use Perlbrew perl5.8.6 then as that user you should be able to run $ perl -v and get 5.8.6. then install all modules that NorthernLight requires manually (you need to list them somehow, but also running the executables and when they fail on ... XXX not found you install it and move on until it stops complaining, it can work) as this user you just created.

Edit: I mean, re-install perl5.8.6 with perlbrew manually. Do not depend on the NortherLight's Perl installation at all. Unless they made proprietary changes to the code, compiled it and now are providing binaries to you. Which obviously has a sell-by date ...

[davebaker]

 
$> /usr/local/ese/bin/perl
$> /usr/local/ese/bin/perl: error while loading shared libraries: libn
+sl.so.1: cannot open shared object file: No such file or directory

/usr/local/ese/bin/perl seems to be a symbolic link (from "ls -al:")

lrwxrwxrwx.  1 root root     28 May 18  2008 perl -> /usr/local/ese/pe
+rl/bin/perl

Executing the target file from the shell seems to produce the same result as executing the link:

$> /usr/local/ese/perl/bin/perl
$> /usr/local/ese/perl/bin/perl: error while loading shared libraries:
+ libnsl.so.1: cannot open shared object file: No such file or directo
+ry

(Edited 11/19/2020 to correct an insignificant typo)

[bliako]

Generally, this error means that that library was not found. The executable you tried to run depends on it. It could be somewhere but not at a location the system looks for libraries. Could it be that the system was upgraded and that library was upgraded too, to a newer version which is no longer ...so.1 ? Nobody stops you from installing older libraries in your system, check with your package manager how to do that (and once you are there check if libnsl is already installed and what version it is). However, that's a symptom which most likely is going to be followed by many more of the same nature.

Can you recompile that special perl you have and all the required modules in the new OS? If yes, then it's worth doing this with perlbrew and then use cpan or cpanm to install all required modules at required versions.

If you can't recompile but you only have binaries, then salva's suggestion building a container with Centos6 + installing those perl binaries is definetely a good option.

If you feel lucky then just keep adding those missing libraries with your package manager trying not mess up your current Centos. But as salva already said, those error messages indicate a 32-bit/64-bit incompatibility, which is much harder to resolve...

[bliako]

I think the first point to clarify is whether you have (perl5.8.6 + XS modules) binaries which can not be re-compiled by you or them on the newest OS (and subsequent upgrades). OR whether you have sources: Perl and modules. If Perl sources were not modified and you can use a stock perl5.8.6 then install it with perlbrew. Else, try to compile it in your new OS, that's a straight-forward route, I don't foresee unsolvable problems with compilation (on a Linux system at least). As for modules, if you have custom modules sources that need to be (compiled and) installed, then just do that manually.

If OTOH you only have a perl5.8.6 binary or XS modules binaries but no sources, then tell us. The longshot is that hopefully, they supplied you with binaries-only but these binaries are nothing special but were compiled from stock, publicly-available sources, in which case it is worth to manually compile and install and see if you get any problems in the program output, tests failing etc.

bw, bliako

[davebaker]

I seem to be successful so far in taking the approach described in your first paragraph -- installing some legacy packages.

Rackspace support installed a glibc.i686 package for 32-bit support (I am told).

I found that libnsl was installed in CentOS 8 already, but by using this incredible "dnf" utility that comes with CentOS 8, I was able to find a legacy package that provides libnsl.so.1 (which the "installed" perl5.8.6 was balking about):

dnf provides libnsl.so.1

resulted in

Last metadata expiration check: 1:34:46 ago on Fri 20 Nov 2020 06:25:4
+1 AM CST.
libnsl-2.28-101.el8.i686 : Legacy support library for NIS
Repo        : @System
Matched from:
Provide    : libnsl.so.1

libnsl-2.28-101.el8.i686 : Legacy support library for NIS
Repo        : BaseOS
Matched from:
Provide    : libnsl.so.1

so I entered the magic command

yum install libnsl-2.28-101.el8.i686

and now the "installed" perl5.8.6 runs (it has the usual bin/man/lib subdirectory structure and their files, including a site_lib/5.8.6 that is full of modules, all of which has been extracted from a huge zipped file by a shell script and essentially copied by that script into a newly created /usr/local/ese directory). I then was successful in running an ESE-supplied "configurator" script that wrote a config file after several prompts at the terminal, and created directories.

I expect I'll run into fatal errors that have to do with other uninstalled "legacy" libraries, when I fire up the "crawler" that does the fetching of HTML pages into a database and then calls some compiled files that massage the data and creates records in a database. I don't have source code for those files, but if/when those crash perhaps I'll see some diagnostic information and then install the needed legacy libraries if they exist in the repo that's being used.

Before learning about the "dnf provides" method from professor Google, I had installed 5.8.9 using perlbrew as you alternatively suggested, and basically replaced the whole /usr/local/ese/perl directory (which contained bin, lib and man directories; the 5.8.6 was in that bin directory) by moving it to a perl.orig directory and adding a symbolic link from /usr/local/ese/perl to /usr/local/ese/perl5/perlbrew/perls/perl-5.8.9. This did indeed work -- the configurator script was able to start running but of course it died each time it couldn't find a "use XYZ" module contained in the /usr/local/ese/perl/lib/site_perl/5.8.6 directory that had come from the ESE installation shell script that had extracted it from a huge zipped file, so I used cpanm (as installed by "perlbrew install-cpanm") to install those modules. I then dubbed myself the all-powerful ruler of the universe, but I was demoted back to serf when the configurator script got to the point of starting up an Apache server (an httpd file that is part of the /usr/local/ese installation), which choked with an error that described a file in a path that included the "5.8.6" string as one of its directory names, to which I decided (for some reason) I wouldn't be able to make an effective symbolic link. The hour was late and I didn't keep a good log. The error also included a reference to a missing Apache.pm, which cpanm wouldn't let me install without specifying the location of Apache source code, so that's when I kinda gave up going down that route and tried your initial suggestion of seeing whether I could just find the "missing" libraries.

REALLY appreciate your help!

[jcb]

Noting bliako's reply above, this suggests that there may be a lib directory that matches that perl somewhere. Try "find /use/local/ese -type d -name lib" to see if there are additional libaries. If so, try running the ESE's perl with those directories in the LD_LIBRARY_PATH environment variable; something like "LD_LIBRARY_PATH=/usr/local/ese/lib:/usr/local/ese/perl/lib /usr/local/ese/bin/perl" should do if find locates those directories. If that works, then you only need to find a way to pass that environment variable into the ESE CGI scripts and all should work.