Originally posted by nidua18
You are absolutely right that this is the problem however I still donít know what this command does?
One thing ldconfig does is create symbolic links (see "man ln" for information on symbolic links) that the run-time linker uses. For example, if you install libwhatever.so.1.2.1, ldconfig creates a symbolic link libwhatever.so.1 that's used to actually dynamically link to. This allows you to upgrade to libwhatever.so.1.3.1, run ldconfig to update the symbolic link, and none of the programs that link against it dynamically need to know about the change because they still link against the symbolic link libwhatever.so.1.
Another important thing it does is maintain a cache of the name and path (and probably more information I don't know about) of available dynamic libraries in /etc/ld.so.cache. The advantage of this is the run-time linker doesn't have to do a time-consuming search through the filesystem looking for libraries to link with. The disadvantage is that it has to be kept up to date; fortunately, this is easy to do by simply running ldconfig.
ldconfig automatically looks in /lib and /usr/lib for libraries. Any other directories you want it to look, for example /usr/local/lib, must be added to /etc/ld.so.conf. The people who put together distributions put the needed entries in /etc/ld.so.conf, so unless you put your libraries in weird places, you shouldn't have to add entries into /etc/ld.so.conf. If running ldconfig doesn't work, check /etc/ld.so.conf to make sure the directory where you put the libraries is there. Don't add directories into /etc/ld.so.conf that are writable by a non-root user.
You can check which dynamic libraries an executable needs and if the run-time linker know about them (i.e., the symbolic links are set up and there is an entry in /etc/ld.so.cache) with the ldd (list dynamic dependencies) command. For example:
ldd $(which ls)
shows the dynamic dependencies of the ls command.
Maybe this will help,