On Sat, 2009-10-31 at 23:58 +1300, Lawrence D'Oliveiro wrote: > I just checked my Debian installation: > > l...@theon:~> find /lib /usr/lib -name \*.so -a -not -name lib\* > -print | wc -l > 2950 > l...@theon:~> find /lib /usr/lib -name \*.so -print | wc -l > 4708 > > So 63% of the shareable libraries on my system have names NOT > beginning with lib. > > Any better theories?
Those are likely not system (sharable) libraries (e.g. libcrypt). These are probably plugins loaded by a specific program, for example PAM modules, ImageMagick plugins, python modules, etc. so since they are not in your library path the do not stand getting accidentally loaded (e.g. when a binary is linked against libcrypt.so). These libraries are loaded directly by the program using their exact path name and dlopen(). The issue with windows they were saying is that Windows will load the library with that name if it is in your current directory. So if you happen to have a python library called CRYPT.DLL and you are in that directory and try to run a program that loads CRYPT.DLL then you will be loading the python module instead of the Windows one (I have no idea if Windows has a CRYPT.DLL). OTOH this doesn't happen in Linux because a) programs wanting the system's crypt library are looking for libcrypt.so and b) Linux doesn't look in your current directory (by default) for libraries. -- http://mail.python.org/mailman/listinfo/python-list
