cannot open shared object file libtclx8.4.so

Clovertech Forums Read Only Archives Cloverleaf Support Web cannot open shared object file libtclx8.4.so

  • Creator
    Topic
  • #52271
    Mike Shoemaker
    Participant

      So much for my first attempt at using Lawson Case for support. Now I need support for using support.

      In any event, I’m attempting to install Cloverleaf 5.6 on a Redhat Ent. 5 server.  I have done it in the past without issue but this time I’m receiving a complaint about libtclx8.4.so not being present.  

      Specifically, i get the complaint when trying to run hcitcl commands. The error says:

      hcitcl: error while loading shared libraries: libtclx8.4.so: cannot open shared object file: No such file or directory

      I’ve checked the env path for TCLX_LIBRARY and it points to /hci/qdx5.6/integrator/tcl/lib/tclx8.4 which is present.  I also see libtclx8.4.so in the /hci/qdx5.6/integrator/tcl/lib/ directory.  All permissions appear to be in order.  Has anyone seen this before?

      I found 1 lonely post in these forums which was not much help but figured I’d take another shot at asking the question while I wait for Lawson Case support to support the support portal.

      Thanks!

    Viewing 3 reply threads
    • Author
      Replies
      • #73639
        Rob Abbott
        Keymaster

          Hi Michael; are you executing “setroot” before hcitcl?  I’ll also have someone contact you regarding CASE.

          Rob Abbott
          Cloverleaf Emeritus

        • #73640
          Mike Shoemaker
          Participant

            Hey Rob,

            I just figured that out, accidentally. Apparently, if i login via telnet as hci everything works fine.  But if I login via the console as hci, i need to setroot.  Which is weird to me because I always thought the .profile had an entry in it to setroot at login.  But I’m good now 🙂  

            I appreciate the help with Case just .. in case.

            Thanks!

          • #73641
            Dirk Engels
            Participant

              Hi Mike,

              there is a difference in the way the shells were used in login in via telnet or on console.

              Login in via telnet uses the .profile, thus you have your environment. If you login via console, the .profile will not be used. The console shell searches for a .bashrc instead. As there is none per default, you don’t have your environment.

              To solve this, just use a .bashrc script, which executes the .profile or even copy .profile to .bashrc. Then you can work with the console window as well.

            • #73642
              Mike Shoemaker
              Participant

                Got it, thanks. I don’t anticipate using the console as hci but I’ll keep it consistent because I know I’ll forget this by the end of the week 😉

                Dirk Engels wrote:

                Hi Mike,

                there is a difference in the way the shells were used in login in via telnet or on console.

                Login in via telnet uses the .profile, thus you have your environment. If you login via console, the .profile will not be used. The console shell searches for a .bashrc instead. As there is none per default, you don’t have your environment.

                To solve this, just use a .bashrc script, which executes the .profile or even copy .profile to .bashrc. Then you can work with the console window as well.

            Viewing 3 reply threads
            • The forum ‘Support Web’ is closed to new topics and replies.