The following excerpt explains why Linux uses "ldconfig" after the installation or uninstallation of a shared library.
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
| On Linux systems, this loader ... finds
| and loads all other shared libraries
| used by the program.
|
| The list of directories to be searched
| is stored in the file /etc/ld.so.conf.
|
| Searching all of these directories at
| program start-up would be grossly
| inefficient, so a caching arrangement is
| actually used. The program ldconfig(8)
| by default reads in the file
| /etc/ld.so.conf, sets up the appropriate
| symbolic links in the dynamic link
| directories (so they'll follow the
| standard conventions), and then writes a
| cache to /etc/ld.so.cache that's then
| used by other programs. This greatly
| speeds up access to libraries. The
| implication is that ldconfig must be run
| whenever a DLL is added, when a DLL is
| removed, or when the set of DLL
| directories changes; running ldconfig is
| often one of the steps performed by
| package managers when installing a
| library. On start-up, then, the dynamic
| loader actually uses the file
| /etc/ld.so.cache and then loads the
| libraries it needs.
How does Mac OS X deal with this issue?
Linux uses the cache file "/etc/ld.so.cache" to avoid the redundant search of directories. Linux uses "ldconfig" to update the cache.
How does Mac OS X avoid the inefficient redundant search of directories?
