{
	"id": "7685a2f8-ea97-4e08-9d2e-ebc71fb384d4",
	"created_at": "2026-04-06T01:29:06.98233Z",
	"updated_at": "2026-04-10T13:12:16.752028Z",
	"deleted_at": null,
	"sha1_hash": "6d59af69922e9bc12c2ebd023e9de7cc4b7ef6ad",
	"title": "Overview of Dynamic Libraries",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 168566,
	"plain_text": "Overview of Dynamic Libraries\r\nPublished: 2012-07-23 · Archived: 2026-04-06 00:08:25 UTC\r\nTwo important factors that determine the performance of apps are their launch times and their memory footprints.\r\nReducing the size of an app’s executable file and minimizing its use of memory once it’s launched make the app\r\nlaunch faster and use less memory once it’s launched. Using dynamic libraries instead of static libraries reduces\r\nthe executable file size of an app. They also allow apps to delay loading libraries with special functionality only\r\nwhen they’re needed instead of at launch time. This feature contributes further to reduced launch times and\r\nefficient memory use.\r\nThis article introduces dynamic libraries and shows how using dynamic libraries instead of static libraries reduces\r\nboth the file size and initial memory footprint of the apps that use them. This article also provides an overview of\r\nthe dynamic loader compatibility functions apps use to work with dynamic libraries at runtime.\r\nWhat Are Dynamic Libraries?\r\nMost of an app’s functionality is implemented in libraries of executable code. When an app is linked with a library\r\nusing a static linker, the code that the app uses is copied to the generated executable file. A static linker collects\r\ncompiled source code, known as object code, and library code into one executable file that is loaded into memory\r\nin its entirety at runtime. The kind of library that becomes part of an app’s executable file is known as a static\r\nlibrary. Static libraries are collections or archives of object files.\r\nWhen an app is launched, the app’s code—which includes the code of the static libraries it was linked with—is\r\nloaded into the app’s address space. Linking many static libraries into an app produces large app executable files.\r\nFigure 1 shows the memory usage of an app that uses functionality implemented in static libraries. Applications\r\nwith large executables suffer from slow launch times and large memory footprints. Also, when a static library is\r\nupdated, its client apps don’t benefit from the improvements made to it. To gain access to the improved\r\nfunctionality, the app’s developer must link the app's object files with the new version of the library. And the apps\r\nusers would have to replace their copy of the app with the latest version. Therefore, keeping an app up to date with\r\nthe latest functionality provided by static libraries requires disruptive work by both developers and end users.\r\nFigure 1  App using static libraries\r\nhttps://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html\r\nPage 1 of 4\n\nA better approach is for an app to load code into its address space when it’s actually needed, either at launch time\r\nor at runtime. The type of library that provides this flexibility is called dynamic library. Dynamic libraries are not\r\nstatically linked into client apps; they don't become part of the executable file. Instead, dynamic libraries can be\r\nloaded (and linked) into an app either when the app is launched or as it runs.\r\nFigure 2 shows how implementing some functionality as dynamic libraries instead of as static libraries reduces the\r\nmemory used by the app after launch.\r\nFigure 2  App using dynamic libraries\r\nhttps://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html\r\nPage 2 of 4\n\nUsing dynamic libraries, programs can benefit from improvements to the libraries they use automatically because\r\ntheir link to the libraries is dynamic, not static. That is, the functionality of the client apps can be improved and\r\nextended without requiring app developers to recompile the apps. Apps written for OS X benefit from this feature\r\nbecause all system libraries in OS X are dynamic libraries. This is how apps that use Carbon or Cocoa\r\ntechnologies benefit from improvements to OS X.\r\nAnother benefit dynamic libraries offer is that they can be initialized when they are loaded and can perform clean-up tasks when the client app terminates normally. Static libraries don’t have this feature. For details, see Module\r\nInitializers and Finalizers.\r\nOne issue that developers must keep in mind when developing dynamic libraries is maintaining compatibility with\r\nclient apps as a library is updated. Because a library can be updated without the knowledge of the client-app’s\r\ndeveloper, the app must be able to use the new version of the library without changes to its code. To that end, the\r\nlibrary’s API should not change. However, there are times when improvements require API changes. In that case,\r\nthe previous version of the library must remain in the user’s computer for the client app to run properly. Dynamic\r\nLibrary Design Guidelines explores the subject of managing compatibility with client apps as a dynamic library\r\nevolves.\r\nHow Dynamic Libraries Are Used\r\nWhen an app is launched, the OS X kernel loads the app’s code and data into the address space of a new process.\r\nThe kernel also loads the dynamic loader ( /usr/lib/dyld ) into the process and passes control to it. The\r\ndynamic loader then loads the app’s dependent libraries. These are the dynamic libraries the app was linked with.\r\nThe static linker records the filenames of each of the dependent libraries at the time the app is linked. This\r\nfilename is known as the dynamic library’s install name. The dynamic loader uses the app’s dependent libraries’\r\ninstall names to locate them in the file system. If the dynamic loader doesn’t find all the app’s dependent libraries\r\nat launch time or if any of the libraries is not compatible with the app, the launch process is aborted. For more\r\ninformation on dependent-library compatibility, see Managing Client Compatibility With Dependent Libraries.\r\nDynamic library developers can set a different install name for a library when they compile it using the gcc -\r\ninstall_name option. See the gcc man page for details.\r\nThe dynamic loader resolves only the undefined external symbols the app actually uses during the launch process.\r\nOther symbols remain unresolved until the app uses them. For details on the process the dynamic loader goes\r\nwhen an app is launched, see “Executing Mach-O Files” in Mach-O Programming Topics.\r\nThe dynamic loader—in addition to automatically loading dynamic libraries at launch time—loads dynamic\r\nlibraries at runtime, at the app’s request. That is, if an app doesn't require that a dynamic library be loaded when it\r\nlaunches, developers can choose to not link the app’s object files with the dynamic library, and, instead, load the\r\ndynamic library only in the parts of the app that require it. Using dynamic libraries this way speeds up the launch\r\nprocess. Dynamic libraries loaded at runtime are known as dynamically loaded libraries. To load libraries at\r\nruntime, apps can use functions that interact with the dynamic loader for the platform under which they're running.\r\nDifferent platforms implement their dynamic loaders differently. They may also have custom dynamic code-loading interfaces that make code difficult to port across platforms. To facilitate porting an app from UNIX to\r\nhttps://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html\r\nPage 3 of 4\n\nLinux, for example, Jorge Acereda and Peter O'Gorman developed the dynamic loader compatibility (DLC)\r\nfunctions. They offer developers a standard, portable way to use dynamic libraries in their apps.\r\nThe DLC functions are declared in /usr/include/dlfcn.h . There are five of them:\r\ndlopen(3) OS X Developer Tools Manual Page : Opens a dynamic library. An app calls this function\r\nbefore using any of the library’s exported symbols. If the dynamic library hasn’t been opened by the\r\ncurrent process, the library is loaded into the process’s address space. The function returns a handle that’s\r\nused to refer to the opened library in calls to dlsym and dlclose . This handle is known as the dynamic\r\nlibrary handle. This function maintains a reference count that indicates the number of times the current\r\nprocess has used dlopen to open a particular dynamic library.\r\ndlsym(3) OS X Developer Tools Manual Page : Returns the address of a symbol exported by a\r\ndynamically loaded library. An app calls this function after obtaining a handle to the library through a call\r\nto dlopen . The dlsym function takes as parameters the handle returned by dlopen or a constant\r\nspecifying the symbol search scope and the symbol name.\r\ndladdr(3) OS X Developer Tools Manual Page : Returns information on the address provided. If the\r\naddress corresponds to a dynamically loaded library within the app’s address space, this function returns\r\ninformation on the address. This information is returned in a Dl_info structure, which encapsulates the\r\npathname of the dynamic library, the library’s base address, and the address and value of the nearest\r\nsymbol to the address provided. If no dynamic library is found at the address provided, the function returns\r\nno information.\r\ndlclose(3) OS X Developer Tools Manual Page : Closes a dynamically loaded library. This function\r\ntakes as a parameter a handle returned by dlopen . When the reference count for that handle reaches 0, the\r\nlibrary is unloaded from the current process’s address space.\r\ndlerror(3) OS X Developer Tools Manual Page : Returns a string that describes an error condition\r\nencountered by the last call to dlopen , dlsym , or dlclose .\r\nFor more information on the DLC functions, see OS X ABI Dynamic Loader Reference.\r\nSource: https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfD\r\nynamicLibraries.html\r\nhttps://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html"
	],
	"report_names": [
		"OverviewOfDynamicLibraries.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775438946,
	"ts_updated_at": 1775826736,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6d59af69922e9bc12c2ebd023e9de7cc4b7ef6ad.pdf",
		"text": "https://archive.orkl.eu/6d59af69922e9bc12c2ebd023e9de7cc4b7ef6ad.txt",
		"img": "https://archive.orkl.eu/6d59af69922e9bc12c2ebd023e9de7cc4b7ef6ad.jpg"
	}
}