[plt-scheme] stdc++ linking problem

Lo, on Wednesday, November 19, David Van Horn did write:

> ld.so.1: mred: fatal: libstdc++.so.5: open failed: No such file or directory
> Killed
> 
> ls /usr/local/lib/libstdc++.* for both systems returns:
> 
> /usr/local/lib/libstdc++.a          /usr/local/lib/libstdc++.so.3@
> /usr/local/lib/libstdc++.la*        /usr/local/lib/libstdc++.so.3.0.0*
> /usr/local/lib/libstdc++.so@
> 
> So I don't see how libstdc++.so.5 can be found on one machine and not the 
> other (I would expect both machines to fail to start MrEd).
> 
> Any ideas?

Since mred is apparently looking for libstdc++.so.5, it must be getting
it out of a different directory; I only see libstdc++.so.3 above.  You
could do a find or locate for libstdc++.so.5, but see below for a faster
method to figure out where it's getting this from.

> Is there some way to do a "which libstdc++" on the system that is working?

Sure: run `ldd' on the mred binary on the working machine.  This will
list all of the shared libraries required by the application and print
the location from which they're loaded.  This doesn't catch
dynamically-loaded libraries, but that shouldn't be an issue for
something as central as libstdc++.

(Side note: in my experience, ldd is fairly common across Unixes, or at
least those that support shared libraries.  It doesn't seem to exist on
my MacOS 10.2.8 machine, though -- does anyone know what the MacOS
equivalent is?)

HTH,

Richard