4 Replies Latest reply on Jun 10, 2009 10:04 AM by R V

    executing "nsh" results in error: libtermcap.so.2 not found

    R V

      Hi all,

       

      I installed nsh (and rscd) on a SuSE x86_64-system using the NSH750-264-RHAS4X86_64.SH installer with the "-local"-option. I set NSHDIR and LD_LIBRARY_PATH to the right values but when I execute "nsh" I get an error:

       

      /bmc/blog/bin/nsh: error while loading shared libraries:
      libtermcap.so.2: cannot open shared object file:
      No such file or directory

      This file isn't present on the system - but - on another system nsh runs correctly even if this file isn't present either.

       

      I made a try with

       

       

      # ln -s /lib64/libncurses.so.5.5 /bmc/blog/lib/libtermcap.so.2



      as I figured out that (at least) one used function ("tgetent") is contained in this lib also --- and after that nsh started.

       

      Does somebody know, why this lib is linked to even if it's - on the one system - not used? And why do I have to have it on the failing system?

        • 1. Re: executing "nsh" results in error: libtermcap.so.2 not found
          Bill Robinson

          is the LD_LIBRARY_PATH=/bmc/blog/lib:$LD_LIBRARY_PATH ?

           

          or did you set it =/bmc/blog/lib ?

          • 2. Re: executing "nsh" results in error: libtermcap.so.2 not found

            Starting with the 7.6 release the release notes now contain the following info:

            #############

            The Network Shell (NSH) requires that the termcap rpm library be

            installed on the machine on which NSH is running.

            To determine if the library is installed, execute the command:

            rpm -qa | grep libtermcap

            If this command does not return any output, you need to install the

            termcap rpm library on the machine.

            #################

             

            While the release note does not distinguish, technically, this should only be applicable to the 64-bit installer. That might be why you're seeing a difference if you're comparing this to a 32-bit install.

             

            Also, while your workaround may work for you, I would not recommend it for the long haul (or for production environments).

             

            This seems to be less of an issue for Redhat 64-bit boxes as they're more inclined to have the libtermcap installed out of the box. So far we've only seen this on Suse boxes.

            • 3. Re: executing "nsh" results in error: libtermcap.so.2 not found
              R V

              Thank you both so far.

               

              64-bit installer. That might be why you're seeing a difference

              if you're comparing this to a 32-bit install.

               

              yes - "the other system" (which works) is a i686-install (without libtermcap installed). I thought it was 64bit... Now I can start the nsh.

               

              Unfortunatly there is a new error while running: run_etl.nsh from this shell.

               

              touch: error while loading shared libraries:
              libblsrp.so: cannot open shared object file:
              No such file or directory

               

              Shurly - /bmc/blog/lib/libblsrp.so exists...

               

              I set LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/bmc/blog/lib, NSHDIR=/bmc/blog and exported both. I think this deals with authentication - but again: where must I look at?

               

              Message was edited by:

              Reinhard Vielhaber

              (added "libblsrp exists")

              • 4. Re: executing "nsh" results in error: libtermcap.so.2 not found
                R V

                This one I solved first with a complete new installation. The error-message disapperad.

                 

                At one time it appeared again. A "which touch" showed, that - inside the normal bash - the nsh-touch was used because /bmc/blog/bin was first in the PATH-variable. Changing this resulted in no more errors of this kind.