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

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!

Replies are listed 'Best First'.
Re^5: Running a perl 5.8.6 CentOS 6-compiled app on a CentOS 8 platform
by bliako (Prior) on Nov 20, 2020 at 16:34 UTC

    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