Rebuild older perl without libnsl?

cniggeler has asked for the wisdom of the Perl Monks concerning the following question:

Hi, we have a custom perl 5.8.9 and want to run on RHEL 8.x but as of v8 libnsl needs to be installed separately. Not an issue for us but some clients have difficulty changing their systems with yum install or what-not. So on our CentOS7 build system, renamed libnsl.so* so they wouldn't be found. The Configure script for perl leaves libnsl out since it's not found, but at the end of the make I see,

LD_LIBRARY_PATH=/home/lint/build/perl/perl-5.8.9 /home/lint/build/perl
+/perl-5.8.9/preload /home/lint/build/perl/perl-5.8.9/libperl.so gcc -
+L/usr/local/lib -o miniperl \
    `echo  gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o
+ reentr.o hv.o av.o perl.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o 
+pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsu
+tils.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_p
+ack.o pp_sort.o  | sed 's/ op.o / /'` \
    miniperlmain.o opmini.o -ldl -lm -lcrypt -lutil -lc 
gcc: error while loading shared libraries: libnsl.so.1: cannot open sh
+ared object file: No such file or directory
make: *** [miniperl] Error 127
[download]

I can't figure out where the shared library request for libnsl.so.1 is coming from! Any suggestions? For instance, would I be better off trying to rebuild perl on a RHEL 8.x system instead? Or perhaps libnsl really is necessary for perl up to and through version x.xx? Thanks!

Comment on Rebuild older perl without libnsl? Download Code

Replies are listed 'Best First'.
Re: Rebuild older perl without libnsl? by Fletch (Bishop) on May 14, 2024 at 22:06 UTC
You may have moved it to another name but one of the other libraries still has a reference. Start with the libraries named and use `ldd` to list their dependencies and keep following back. Another alternative would be to use something like `strace -e %file` and watch for access of share libraries; the likely culprit is the last opened before it goes looking for the nsl one. The cake is a lie. The cake is a lie. The cake is a lie.	[reply] [d/l] [select]
Re: Rebuild older perl without libnsl? by cavac (Prior) on May 17, 2024 at 12:16 UTC
custom perl 5.8.9 You are knowingly running a Perl version that has been out of support for 16 years and has numerous unfixed security problems. Ouch! Depending on your jurisdiction, you could face all kinds of criminal and civil lawsuits if this piece of software gets exploited. Instead of trying to keep that ancient piece of history on life support, you really should be looking into upgrading to a new version that gets security fixes. If the comeback is the usual "the customer/my IT department wont allow it", make sure the person blocking the upgrade gives that to you in writing (preferably signed)! You don't want to be personally held responsible for any monetary damages resulting from exploiting the weaknesses in your software (or possibly even go to prison, if push comes to shove). PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP	[reply]
Re: Rebuild older perl without libnsl? by etj (Priest) on May 15, 2024 at 13:05 UTC
I'd look at `perl -V` (yes, I'm just going to use Markdown conventions because typing actual HTML is agonising). The Perl will likely have `-lnsl` in its `libs` and `perllibs` config settings (see e.g. `perl -V:libs` ), and that's getting picked up here. EUMM actually filters through provided `-l` values in its `LIBS` and removes ones that don't work.	[reply] [d/l] [select]