I'm sure you are asking about ELF shared objects (.so libraries), which are a raw equivalent of DLLs under windows? The answer is: It depends.

The version number of shared objects is supposed to consist of two parts, a major number, that only changes, iff there are incompatible ABI changes; and a minor number that changes if the changes are backwards compatible (maybe called "revision"). The name then is lib<name>.so.<major>.<minor> E.g. on my system i find

> ls -l /lib/libreadline.so*
lrwxrwxrwx  1 root root     18 Jul 12 17:29 /lib/libreadline.so.4 -> libreadline.so.4.3
-rw-r--r--  1 root root 173884 Jun 13  2004 /lib/libreadline.so.4.3
lrwxrwxrwx  1 root root     18 Jul 12 17:29 /lib/libreadline.so.5 -> libreadline.so.5.0
-rw-r--r--  1 root root 178268 Jan 23  2005 /lib/libreadline.so.5.0

and

> ls -l /usr/lib/libreadline.so*
lrwxrwxrwx  1 root root 21 Jul 12 17:29 /usr/lib/libreadline.so -> /lib/libreadline.so.5

I.e. programs linked against /usr/lib/libreadline.so (via -L/usr/lib -lreadline) will /really/ be linked against /lib/libreadline.so.5 (the newest ABI version installed on the system / the one matching the header files in /usr/include; both the header files and the symlink are in the libreadline5-dev package). This way the ABI version is recorded in the executable.

When the program is started, the runtime linker finds, that /lib/libreadline.so.5 actually is libreadline.so.5.0 in this case, but if a backwards compatible new version comes out, libreadline.so.5.1 will be used instead.

Old libreadline4-linked executables still run (getting version 4.3), until i remove the libreadline4 package; even though i can't easily create /new/ executables linked against this old version (only by installing the libreadline4-dev package instead of libreadline5-dev. That's why library and -dev packages are seperated, only one of the -dev packages can be installed, but multiple ABI versions of the library.

ldconfig of course has to implement this policy. The 2nd level symlinks which select the current minor versions (4 -> 4.3 for example) are actually created by ldconfig, it seems. (The other role of ldconfig is to remember, in which directory libreadline4 is lying, in this case not in /usr/lib like many other libraries, but in /lib (it is needed for bringing up the system / system maintenance), and for faster startup it is good not having to search the library path). It has to treat different major versions as separate libraries, because they are not interchangable, but can choose between the minor versions.