< Previous PageNext Page > Hide TOC

Overview of Dynamic Libraries

Two important factors that determine the performance of applications are their launch times and their memory footprints. Reducing the size of an application’s executable file and minimizing its use of memory once it’s launched make the application launch faster and use less memory once it’s launched. Using dynamic libraries instead of static libraries reduces the executable file size of an application. They also allow applications to delay loading libraries with special functionality only when they’re needed instead of at launch time. This feature contributes further to reduced launch times and efficient memory use.

This article introduces dynamic libraries and shows how using dynamic libraries instead of static libraries reduces both the file size and initial memory footprint of the applications that use them. This article also provides an overview of the dynamic loader compatibility functions applications use to work with dynamic libraries at runtime.


What Are Dynamic Libraries?
How Dynamic Libraries Are Used

What Are Dynamic Libraries?

Most of an application's functionality is implemented in libraries of executable code. When an application is linked against a library using a static linker, the code that the application uses is copied to the generated executable file. A static linker collects compiled source code, known as object code, and library code into one executable file that is loaded into memory in its entirety at runtime. The kind of library that becomes part of an application's executable file is known as a static library. Static libraries are collections or archives of object files.

Note: Static libraries are also known as static archive libraries and static linked shared libraries.

When an application is launched, the application’s code—which includes the code of the static libraries it was linked against—is loaded into the application’s address space. Linking many static libraries into an application produces large application executable files. Figure 1 shows the memory usage of an application that uses functionality implemented in static libraries. Applications with large executables suffer from slow launch times and large memory footprints. Also, when a static library is updated, its client applications don’t benefit from the improvements made to it. To gain access to the improved functionality, the application’s developer must link the application's object files against the new version of the library. And the applications users would have to replace their copy of the application with the latest version. Therefore, keeping an application up to date with the latest functionality provided by static libraries requires disruptive work by both developers and end users.

Figure 1  Application using static libraries

A better approach is for an application to load code into its address space when it’s actually needed, either at launch time or at runtime. The type of library that provides this flexibility is called dynamic library. Dynamic libraries are not statically linked into client applications; they don't become part of the executable file. Instead, dynamic libraries can be loaded (and linked) into an application either when the application is launched or as it runs.

Note: Dynamic libraries are also known as dynamic shared libraries, shared objects, or dynamically linked libraries.

Figure 2 shows how implementing some functionality as dynamic libraries instead of as static libraries reduces the memory used by the application after launch.

Figure 2  Application using dynamic libraries

Using dynamic libraries, programs can benefit from improvements to the libraries they use automatically because their link to the libraries is dynamic, not static. That is, the functionality of the client applications can be improved and extended without requiring application developers to recompile the applications. Applications written for Mac OS X benefit from this feature because all system libraries in Mac OS X are dynamic libraries. This is how applications that use Carbon or Cocoa technologies benefit from improvements to Mac OS X.

Another benefit dynamic libraries offer is that they can be initialized when they are loaded and can perform clean-up tasks when the client application terminates normally. Static libraries don’t have this feature. For details, see “Module Initializers and Finalizers.”

One issue that developers must keep in mind when developing dynamic libraries is maintaining compatibility with client applications as a library is updated. Because a library can be updated without the knowledge of the client-application's developer, the application must be able to use the new version of the library without changes to its code. To that end, the library’s API should not change. However, there are times when improvements require API changes. In that case, the previous version of the library must remain in the user’s computer for the client application to run properly. “Dynamic Library Design Guidelines” explores the subject of managing compatibility with client applications as a dynamic library evolves.

How Dynamic Libraries Are Used

When an application is launched, the Mac OS X kernel loads the application’s code and data into the address space of a new process. The kernel also loads the dynamic loader ( /usr/lib/dyld ) into the process and passes control to it. The dynamic loader then loads the application’s dependent libraries. These are the dynamic libraries the application was linked against. The static linker records the filenames of each of the dependent libraries at the time the application is linked. This filename is known as the dynamic library’s install name. The dynamic loader uses the application’s dependent libraries’ install names to locate them in the file system. If the dynamic loader doesn’t find all the application’s dependent libraries at launch time or if any of the libraries is not compatible with the application, the launch process is aborted. For more information on dependent-library compatibility, see “Managing Client Compatibility With Dependent Libraries.” Dynamic library developers can set a different install name for a library when they compile it using the gcc -install_name option. See the gcc man page for details.

The dynamic loader resolves only the undefined external symbols the application actually uses during the launch process. Other symbols remain unresolved until the application uses them. For details on the process the dynamic loader goes when an application is launched, see “Executing Mach-O Files” in Mach-O Programming Topics.

The dynamic loader—in addition to automatically loading dynamic libraries at launch time—loads dynamic libraries at runtime, at the application's request. That is, if an application doesn't require that a dynamic library be loaded when it launches, developers can choose to not link the application's object files against the dynamic library, and, instead, load the dynamic library only in the parts of the application that require it. Using dynamic libraries this way speeds up the launch process. Dynamic libraries loaded at runtime are known as dynamically loaded libraries. To load libraries at runtime, applications can use functions that interact with the dynamic loader for the platform under which they're running.

Note: The target architecture of the client and the dynamic library must be the same. Otherwise, the dynamic loader doesn’t load the library.

Different platforms implement their dynamic loaders differently. They may also have custom dynamic code-loading interfaces make code difficult to port across platforms. To facilitate porting an application from UNIX to Linux, for example, Jorge Acereda and Peter O'Gorman developed the dynamic loader compatibility (DLC) functions. They offer developers a standard, portable way to use dynamic libraries in their applications.

The DLC functions are declared in /usr/include/dlfcn.h. There are five of them:

For more information on the DLC functions, see Mac OS X ABI Dynamic Loader Reference.

< Previous PageNext Page > Hide TOC

© 2009 Apple Inc. All Rights Reserved. (Last updated: 2009-02-26)

Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.