If your web browser formats this page incorrectly, try viewing the page source. In netscape 4, click the view menu, then click page source. Usually you have a library named something like 'libfoo.so.2.4.8'. There should also be links named 'libfoo.so' and 'libfoo.so.2'. Both links will link to libfoo.so.2.4.8. libfoo.so.2.4.8 should have a name stored inside the file, which you can find with a viewer like less if you know where to look. The name stored inside libfoo.so.2.4.8 should be 'libfoo.so.2'. However, sometimes the name stored inside a library is 'libfoo.so.2.4' or 'libfoo.so.2.4.8' or even 'libfoo.so'. This may mean that the person who created the library set the name incorrectly, but usually this is not a problem. The link named libfoo.so is used by gcc or ld when compiling and linking a program. When gcc or ld is instructed to link a program to library 'foo', gcc or ld searches the lib directories for a file named 'libfoo.so'. If libfoo.so is not found or if gcc or ld is attempting to link statically, gcc or ld look for a file name 'libfoo.a'. If gcc or ld find libfoo.so, gcc or ld read libfoo.so and find the name stored inside libfoo.so. Then gcc or ld will add data to the program that the program requires the name from inside libfoo.so, which is probably libfoo.so.2. When you run a program, if the program requires libfoo.so.2, ld-linux searches the lib directories for a file named libfoo.so.2. ld-linux first searches the directories listed in environment parameter LD_LIBRARY_PATH. If LD_LIBRARY_PATH is not set or if LD_LIBRARY_PATH did not contain libfoo.so.2, then ld-linux searches the libraries listed in /etc/ld.so.cache. /etc/ld.so.cache is created by ldconfig using the directories listed in /etc/ld.so.conf. If ld-linux did not find libfoo.so.2 in /etc/ld.so.cache, ld-linux looks in /lib and /usr/lib. If there is more than one file named libfoo.so.2, then ld-linux uses the version of libfoo.so.2 which ld-linux found first. If the first libfoo.so.2 does not have the symbol or library function which the program requires, ld-linux aborts and does not run the program. ld-linux does not look to see if there is another libfoo.so.2. But if you have more than one libc, then ld-linux usually uses the libc which has the highest version number, even if that libc is not listed first. If the libc failed, ld-linux does not look for another libc. I am not sure if this is because of ld-linux changing the order in /etc/ld.so.cache or ldconfig changing the order in /etc/ld.so.conf. If you have multiple computers networked together or multiple linux distributions on seperate partitions and want to include all the libraries, there is likely to be problems if you include a libc which is newer than the libc in the current linux. List the library directories from the current linux before the library directories from the other linuxes in /etc/ld.so.conf, and do not include /lib from any of the other linuxes unless you are sure that the other linux is older than the current linux. I think that ld-linux can find libraries faster from /etc/ld.so.cache than from LD_LIBRARY_PATH, so you probably want to put all your library directories in /etc/ld.so.conf, run ldconfig, and leave LD_LIBARY_PATH unset. /lib and /usr/lib are searched automatically for libraries which were not found elsewhere, so many linux distributions do not include /lib and /usr/lib in /etc/ld.so.conf. However, ld-linux may be able to find the libraries faster if the libraries are in /etc/ld.so.cache, so I think /lib and /usr/lib should be included in /etc/ld.so.conf. Also, if /lib and /usr/lib are excluded from /etc/ls.so.conf, then ld-linux will search /lib and /usr/lib last; so ld-linux will find /usr/local/lib/libfoo.so.2 before /lib/libfoo.so.2, and ld-linux will use /usr/local/lib/libfoo.so.2 instead of /lib/libfoo.so.2. I think that /lib and /usr/lib should be searched first, so /lib and /usr/lib should be listed at the beginning of /etc/ld.so.conf. In theory, multiple versions of the same library are compatible and interchangeable if the versions have the same major version number (although some versions may have more bugs than others). In reality, it does not always work. If you use a program from one linux distribution with a library from a different linux distribution, there may be problems. ld-linux may say that the library is missing a symbol or function which the program requires, or the program may fail with a segmentation fault. The same is true for different versions of ld-linux. I once had a program which required a library, but ld-linux said the library was missing a function. I switched to a slightly different version of ld-linux which had the same major version number, and the program worked fine. In theory, this sort of thing should not happen. I do not think these problems are caused by bugs. I think these problems are caused by a failure of the library developers to enforce total compatibility. If the library developers make a change in the library which is incompatible with previous versions, the library developers are supposed to change the major version number. But the library developers sometimes do not change the major version number if the new version is mostly compatible but not totally compatible with the old version. The best solution to these problems is to use a linux distribution, and do not use any programs, libraries, or versions of ld-linux other than those which are included in your linux distribution. Especially do not replace your libc with a different libc. Suppose you have a program which requires libfoo.so.2 and you do not have libfoo.so.2 but you do have libfoo.so.3. Probably most of libfoo.so.3 is the same as libfoo.so.2, but a few parts are probably different. If you are lucky, your program will only use parts of libfoo.so.2, and those parts will be the same in libfoo.so.3, and your program might work. Try making libfoo.so.2 a link to libfoo.so.3. Sometimes this works and sometimes this does not work. There is no way to know whether or not it will work except by trying it. I had Fedora Core 2 and installed an mplayer binary which was intended for Mandrake 10. The mplayer binary required libdv.so.2, but FC2 had libdv.so.4. I created a link /usr/fakelibs/libdv.so.2 which linked to /usr/lib/libdv.so.4. I though it was a good idea to put the substitute libraries in a seperate directory, so the substitute libraries directory could be listed last in /etc/ld.so.conf, so all other libraries would take precedence over the substitute libraries. If I ever installed the real library, the substitute library would not interfere with the installation of the real library, and the real library would be used instead of the substitute library even if I forgot to delete the substitute library. I put /usr/fakelibs last in /etc/ld.so.conf and ran ldconfig. But mplayer would not run. The substitute libraries were not found. I looked in /etc/ld.so.cache. /usr/fakelibs/libdv.so.2 was listed in /etc/ld.so.cache, but it was listed as libdv.so.4, not as libdv.so.2. Then I made a link /usr/lib/libdv.so.2 which linked to libdv.so.4, and it worked. So ldconfig lists libraries in /etc/ld.so.cache by the internal name, not by the file name. It is useless to include substitute libraries in /etc/ld.so.conf or to run ldconfig after installing substitute libraries, because ldconfig will not list the substitute libraries in /etc/ld.so.cache. Substitute libraries must be in /usr/lib, not in a seperate directory, because /usr/lib is searched if the library was not found in /etc/ld.so.cache. Probably /lib would work. Probably substitute libraries could be included in LD_LIBRARY_PATH. Many library packages include links and an install script which runs ldconfig. This is sort of redundant, because ldconfig will create the links automatically. However, sometimes different libraries use the same links, so including the links in the package allows your package manager to warn you about the conflict. And every library installation needs to run ldconfig to update /etc/ld.so.cache. I am not sure how ldconfig resolves conflicting links. If ldconfig wants to create a link, and there is already a link with the same name, and ldconfig thinks the prexisting link is incorrect, ldconfig will delete the prexisting link. But if a prexisting link does not conflict with a link which ldconfig creates, then ldconfig does not delete the prexisting link, even if the link is wrong. Some library packages include such extra links, especially if the library is a replacement for some other library. For example, libaa (ascii art graphics) may have a link named libvga (svga graphics), so that programs which require libvga will use libaa instead. These links are not redundant. ldconfig will neither create nor delete these links. But if the real libvga exists, ldconfig will create links to the real libvga, which will conflict with the libvga links to libaa, and so ldconfig will delete the libvga links to libaa. If you have a weird program which needs an alternate version of a library, you could try this: #!/bin/sh export LD_LIBRARY_PATH=/alternate_libraries:$LD_LIBRARY_PATH exec weird_program $* or this: #!/bin/sh exec /alternate_libraries/ld-linux.so.2 \ --library-path /alternate_libraries \ weird_program $* But it probably won't work. If you really want to use a program from a different linux distribution, try installing the program with the libraries and ld-linux from that linux distribution in a special directory, and chroot to that directory. Or install the complete distribution on a seperate hard drive partition, and reboot to that linux. Older programs with newer libraries are more likely to work than newer programs with older libraries. libc 4 is a.out and requires /lib/ld.so; and is used with most linux 1.x kernels. libc 5 is glibc and elf and requires /lib/ld-linux.so.1; and is used with the last 1.2 and first 2.0 kernels. libc 6 is glibc 2 and elf and requires /lib/ld-linux.so.2; and is used with most linux 2.x kernels. libc 5 has the fewest compatibility problems, which is probably because libc 5 was not used for very long, and there are not many versions of libc 5. libc 6 has the most compatibility problems, which is probably because libc 6 has been used for a long time, and there are many versions of libc 6. On my redhat 5.0 cdrom, I have two versions of the slang library: RedHat/RPMS/slang-0.99.38-2.i386.rpm and contrib/i386/slang-1.0.3-2.i386.rpm. There is also two versions of Midnight Commander, which uses libslang.so.0: RedHat/RPMS/mc-4.1.8-2.i386.rpm and contrib/i386/mc-4.1.16-1.i386.rpm mc 4.1.16 says segmentation fault if libslang.so.0 is link to libslang.so.1.0.3 mc 4.1.16 says segmentation fault if libslang.so.0 is link to libslang.so.0.99.38 mc 4.1.8 works if libslang.so.0 is link to libslang.so.0.99.38 mc 4.1.8 does not work if libslang.so.0 is link to libslang.so.1.0.3 It starts and displays the files in the current directory, but displays error messages and/or aborts in response to most keystrokes, and it messes up the display, so that you have to exit the shell and log in again to fix the display. For example, if I press the down arrow, it says: "/usr/bin/mc: error in loading shared libraries: undefined symbol: SLsys_getkey" and aborts. On my redhat 5.0 cdrom, there is an rpm in the contribs for pdmenu; according to ldd it requires both libc 5 and libc 6. How can it require both? If I try to run pdmenu, it says segmentation fault and core dump. If I run ldd pdmenu, it says there is no libc 5. How come the linker does not say that when I try to run it? Maybe pdmenu requires libc 5 and also some other libs, and the other libs requires libc 6.