Hey,

This should be a pretty easy answer since I'm sure I'm not the first to have this problem. I have some binaries I've brought over from a redhat 8 (gcc 3.2) machine to a new computer running Fedora 1 for x86-64.

When I run the program I get the following error message:
[mpbottig@indra linux]$ ./startup_mgr
./startup_mgr: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

Ok, that's understandable. The manager can't find that lib because it's not in the same place it was when this program was compiled. On this machine libstdc++.so.5 is in /usr/lib/lib64, not /usr/lib. So, how do I tell the executable to look somewhere else? I read through a bunch of posts that say to run some form of ldconfig, but according to ldconfig the library is right where it's supposed to be. What do I do next?

Actually, as totally irritating as this problem is, I think maybe getting a good explanation of ld-linux, and ELF binaries would help a great deal as well.

"So, how do I tell the executable to look somewhere else?"

You set up symbolic links from where the program is looking to where the library routine is really located. For example:
ln -s /usr/lib/lib64/libstdc++.so.5 /usr/lib/libstdc++.so.5

At which point you may run into a problem with a program compiled to run on a 32 bit machine running library routines compiled to run on a 64 bit machine. Maybe not. You can try it and see if it works.

The ultimate solution is to compile the programs on the new machine.

___________________________________
Be prepared. Create a LifeBoat CD.
http://users.rcn.com/srstites/LifeB....home.page.html

Steve Stites

Actually, I tried that before I sent out this post. Someone on experts exchange hypothesized, like you, that I'm going to have trouble getting a 32 bit program to play nicely with the 64bit libs. I was kinda hoping that since the architecture was built around the idea that you could run legacy 32bit apps along side 64bit apps I wouldn't need more libs. Maybe I'm not that lucky. Anyway, I'll post my findings when I get this working.

32 bit aaplications are not considered legacy my friend.

Well, the solution for me was to install a number of 32 bit versions of my libarary packages. Virutally all my problems disappeared after I got the 32bit libs on the system. I had to break down and just plain copy a couple of the libraries off of P4, but almost everything went on w/o conflicting with previously installed packages.

After they were installed running /sbin/ldconfig -n /usr/[libdir] set everything up.

32 bit apps are not in my opinion "legacy" per say, but the ones I'm working with are off of RH 6.2 systems and use Motif instead of gtk or qt. As lame as these apps are, I'd consider them legacy