Let\'s say I \'ve added a library foo.so.1.1.1 to a path that is included in /etc/ld.so.conf
When I run ldconfig on the system I get the links foo.so.1.1 and foo.so
ldconfig looks inside all shared objects that it finds, to look for the soname. It then creates a link using that soname as the name of the link. It's conventional (but far from universally done) for the soname to be the name and major version of the library, so your library foo.so.1.1 will have a soname of foo.so.1 and ldconfig will make a link called that.
No part of the run-time system looks for or knows anything about the name foo.so. That's used when you link your programs to the library. There's no point in having that link unless you also have all the other development files (headers etc) for the library, so there's no point in ldconfig automatically creating it. And since the name of the link to use is only another convention, and in this case isn't stored inside the file at all, there's no way for ldconfig to know what name to create.
Normally this would be created manually, in the install target of the Makefile; when a library is packaged for a linux distribution the link normally lives in the -dev package along with the header files.
Just make the symlink yourself:
ln -s /usr/lib/foo.so.1.1.1 /usr/lib/foo.so
Note that for applications to use libraries in this manner, they need to be explicitly linked against the unversioned shared object. IE: this is a mechanism to bypass the dynamic loader's version matching system completely.