Dynamic libraries and plug-ins behave differently in Mac OS X than in other operating systems. This section explains some of those differences.
Using Dynamic Libraries at Link Time
Using Dynamic Libraries Programmatically
Compiling Dynamic Libraries and Plugins
When linking an executable, Mac OS X treats dynamic libraries just like libraries in any other UNIX-based or UNIX-like operating system. If you have a library called libmytool.a, libmytool.dylib, or libmytool.so, for example, all you have to do is this:
ld a.o b.o c.o ... -L/path/to/lib -lmytool |
As a general rule, you should avoid creating static libraries (.a) except as a temporary side product of building an application. You must run ranlib on any archive file before you attempt to link against it.
Mac OS X makes heavy use of dynamically linked code. Unlike other binary formats such as ELF and xcoff, Mach-O treats plug-ins differently than it treats shared libraries.
The preferred mechanism for dynamic loading of shared code, beginning in Mac OS X v10.4 and later, is the dlopen family of functions. These are described in the man page for dlopen. The ld and dyld man pages give more specific details of the dynamic linker’s implementation.
Note: By default, the names of dynamic libraries in Mac OS X end in .dylib instead of .so. You should be aware of this when writing code to load shared code in Mac OS X.
Libraries that you are familiar with from other UNIX-based systems might not be in the same location in Mac OS X. This is because Mac OS X has a single dynamically loadable framework, libSystem, that contains much of the core system functionality. This single module provides the standard C runtime environment, input/output routines, math libraries, and most of the normal functionality required by command-line applications and network services.
The libSystem library also includes functions that you would normally expect to find in libc and libm, RPC services, and a name resolver. Because libSystem is automatically linked into your application, you do not need to explicitly add it to the compiler’s link line. For your convenience, many of these libraries exist as symbolic links to libSystem, so while explicitly linking against -lm (for example) is not needed, it will not cause an error.
To learn more about how to use dynamic libraries, see Dynamic Library Programming Topics.
For the most part, you can treat dynamic libraries and plugins the same way as on any other platform if you use GNU libtool. This tool is installed in Mac OS X as glibtool to avoid a name conflict with NeXT libtool. For more information, see the manual page for glibtool.
You can also create dynamic libraries and plugins manually if desired. As mentioned in “Using Dynamic Libraries Programmatically,” dynamic libraries and plugins are not the same thing in Mac OS X. Thus, you must pass different flags when you create them.
To create dynamic libraries in Mac OS X, pass the -dynamiclib flag.
To create plugins, pass the -bundle flag.
Because plugins can be tailored to a particular application, the Mac OS X compiler provides the ability to check these plugins for loadability at compile time. To take advantage of this feature, use the -bundle_loader flag. For example:
gcc -bundle a.o b.o c.o -o mybundle.bundle \ |
-bundle_loader /Applications/MyApp.app/Contents/MacOS/MyApp |
If the compiler finds symbol requests in the plugin that cannot be resolved in the application, you will get a link error. This means that you must use the -l flag to link against any libraries that the plugin requires as though you were building a complete executable.
Important: Mac OS X does not support the concept of weak linking as it is found in systems like Linux. If you override one symbol, you must override all of the symbols in that object file.
To learn more about how to create and use dynamic libraries, see Dynamic Library Programming Topics.
Last updated: 2008-04-08