Why can't libMx.so.3 be found?

[Felecha]

We have a system at a customer site in Alabama that has several Windows machines and one Linux machine, Red Hat 9. We have been using pcAnywhere to get remote access from the office in New Hampshire to one of the Windows boxes and from there to the others. So from here we get complete access to all the Windows machines there.

Recently we upgraded to pcAnywhere 11.5 which allows us to get into the Linux box. We tried it here with a mockup, got it to work, and now our technician is on site there and trying to do the same setup but it's failing. When we do pcAnywhere's Quick Deploy and Connect it apparently loads a thin host on the Linux to connect to. In the log I find the following error:

/root/pcADeploy/thinhost: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory

So I poked around on the Linux box here that is working and found the file libXm.so.3 in usr/X11R6/lib. I changed the file name temporarily and tried to connect and got exactly the same error in the log here. So I loaded the file over the wire to the system down there, in the same directory. Still we get the same error. Then I found that libXm.so.3 is a link to libXm.so.3.0.1 so I sent that down to Alabama. Still the error.

On a Google search I found a forum where someone asked the guy with the problem - is usr/X11R6/lib in your etc/ld.so.conf file? From what I can gather that is a file that is like a PATH thing - telling you where you can find .so files? It is in the conf file here, and I see it in the conf file down there.

So the question is - how is it that libXm.so.3 can't be found? The file is there and the path is in the conf file. Is there more that is needed that I don't know about?

 

[Felecha]

I've found another web clue - someone mentions that the ld.so loader uses a variable LD_LIBRARY_PATH. I haven't found that anywhere on the working system here. Maybe that is needed to tell Linux where to look?

It does seem to be that it doesnt know where to look, not that the files are not there

 

[n0cmonkey]

If the ld.so.conf file is setup correctly, you shouldn't need to set LD_LIBRARY_PATH. ld.so.conf is the correct way to fix this permenantly, but you can test by setting the variable LD_LIBRARY_PATH=/usr/X11R6/lib

I'm confused as to why you are using pcanywhere instead of something better, like OpenSSH.

 

[Nothinman]

If it's listed properly in /etc/ld.so.conf you might have to run ldconfig to update the cache. And I agree with n0c, using PCA on a Linux box seems like a really bad idea.

 

[Felecha]

Well, 2 things.

It looks like the guy here who tried it out here and got it to work and then wrote it up for the tech guy to do the same left something out of the instructions. The tech guy is heading over to the site as I write, to try again with installing the stuff he needs off the installation CD (Adding some RPM stuff). So maybe that will be all that the problem has been all along

And most of this is new to me, this remote stuff. We use pcAnywhere because the company has used it for a long time. We recently started using UltraVNC for getting into the first computer at customer sites and then piggy-backed into the others with pcAnywhere when we found that UltraVNC caused some problems with the running software on those boxes (it was a long time ago that we found we couldnt use UltraVNC everywhere, I forget the issue). It's only recently that we learned there was any way to see the Linux from Windows.

The only line in from here to there is a dialup to the modem on the first Windows box. Due to security the customers have not allowed us to be on their networks. Dialup is a pain but it's still wonderful to have remote access of any kind. A hundred years ago that would have been impossible.

Anyway, if there are other things out there we should look at them I guess. Basically we need to get at the desktops of the customer machines