Editing Shared library (section)

==Locating libraries at runtime==
Loaders for shared libraries vary widely in functionality. Some depend on the executable storing explicit paths to the libraries. Any change to the library naming or layout of the file system will cause these systems to fail. More commonly, only the name of the library (and not the path) is stored in the executable, with the operating system supplying a method to find the library on disk, based on some algorithm.

If a shared library that an executable depends on is deleted, moved, or renamed, or if an incompatible version of the library is copied to a place that is earlier in the search, the executable would fail to load. This is called ''[[dependency hell]]'', existing on many platforms. The (infamous) Windows variant is commonly known as [[DLL hell]]. This problem cannot occur if each version of each library is uniquely identified and each program references libraries only by their full unique identifiers. The "DLL hell" problems with earlier Windows versions arose from using only the names of libraries, which were not guaranteed to be unique, to resolve dynamic links in programs. (To avoid "DLL hell", later versions of Windows rely largely on options for programs to install private DLLs&mdash;essentially a partial retreat from the use of shared libraries&mdash;along with mechanisms to prevent replacement of shared system DLLs with earlier versions of them.)

===Microsoft Windows===
[[Microsoft Windows]] checks the [[Windows registry|registry]] to determine the proper place to load DLLs that implement [[Component Object Model|COM objects]], but for other DLLs it will check the directories in a defined order. First, Windows checks the directory where it loaded the program (''private DLL''<ref name="endofdllhell"/>); any directories set by calling the <code>SetDllDirectory()</code> function; the System32, System, and Windows directories; then the current working directory; and finally the directories specified by the PATH [[environment variable]].<ref>{{cite web
 |url         = http://msdn.microsoft.com/en-us/library/ms682586.aspx
 |title       = Dynamic-Link Library Search Order
 |work        = Microsoft Developer Network Library
 |publisher   = Microsoft
 |date        = 2012-03-06
 |access-date  = 2012-05-20
 |url-status     = live
 |archive-url  = https://web.archive.org/web/20120509160536/http://msdn.microsoft.com/en-us/library/ms682586.aspx
 |archive-date = 9 May 2012
}}</ref> Applications written for the [[.NET Framework]] (since 2002), also check the [[Global Assembly Cache]] as the primary store of shared dll files to remove the issue of [[DLL hell]].

===OpenStep===
[[OpenStep]] used a more flexible system, collecting a list of libraries from a number of known locations (similar to the PATH concept) when the system first starts. Moving libraries around causes no problems at all, although users incur a time cost when first starting the system.

===Unix-like systems===
Most [[Unix-like]] systems have a "search path" specifying file-system [[Directory (computing)|directories]] in which to look for dynamic libraries. Some systems specify the default path in a [[configuration file]], others hard-code it into the dynamic loader. Some [[executable|executable file]] formats can specify additional directories in which to search for libraries for a particular program. This can usually be overridden with an [[environment variable]], although it is disabled for [[setuid]] and setgid programs, so that a user can't force such a program to run arbitrary code with root permissions. Developers of libraries are encouraged to place their dynamic libraries in places in the default search path. On the downside, this can make installation of new libraries problematic, and these "known" locations quickly become home to an increasing number of library files, making management more complex.