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
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 commandyum 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