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

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!

[bliako]

That's cool.

I believed that one can install multiple versions of some library in linux using a package manager but that does not look possible on closer but still diagonal look. I mention this because a lot of system packages may require the latest libnsl (assuming 1.0 is not the latest) and so by having the package manager installing an older version you keep the system not up-to-date. So, assuming 1.0 is not the latest, you can manually fetch and compile libnsl_1.0 and then copy libnsl.so.1.0 to the system-wide library path and also make a link to libnsl.so.1 BUT do not modify any other links (notably libnsl.so -> libnsl.so.2). In my system dnf has superceded yum btw.

You mentioned that ESE requires Apache server. Is that because it provides a web-API to interact with it? If one can communicate with ESE using http or REST then things can become much simpler. You dedicate a Centos6 machine to ESE and talk to it using your up-to-date centos8 from inside the firewall. I don't know how this will play with security when ESE crawls the web. And still centos6 will someday pack up unsupported.

bw, bliako