You can see all the shared library linked dependencies of a program by using comamnd ldd. For example:

$ ldd /bin/ls
    linux-gate.so.1 =>  (0xb76fe000)
    libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb76be000)
    librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb76b5000)
    libacl.so.1 => /lib/i386-linux-gnu/libacl.so.1 (0xb76ab000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7506000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7501000)
    /lib/ld-linux.so.2 (0xb76ff000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb74e6000)
    libattr.so.1 => /lib/i386-linux-gnu/libattr.so.1 (0xb74e0000)

Now, if you want to run this program in another machine and have problems with the version of the shared libraries you can try copying the lot to a directory and then use the LD_LIBRARY_PATH trick. But note that some libraries must not be copied:

• linux-gate.so: Not a real file, but a gateway to kernel land.
• /lib/ld-linux-so.2: The dynamic loader, (or ELF interpreter, as some call it). There is a static reference to it in the header of every dynamically linked executable. Do not copy it.
• [/usr]/lib/i386-linux-gnu/*: Everything in this directory is architecture specific. It may work if both machines have the same architecture. If not, you have to look for a library with the same name under [/usr]/lib/<your-real-arch>/*.

In the target machine, you can also use the ldd tool after export LD_LIBRARY_PATH=... to see if it is resolving the libraries as expected.