Metapkg:dyld and the Darwin Linker
From the Fink Wiki
(this is a work in progress -- for now it's kind of unorganized, it's better to get things down and rearrange later than to never getting around to writing this =)
Libraries on Mac OS X
Shared libraries on Mac OS X are rather different than most other unixes. Mac OS X (or, more specifically, its implementation of the Mach-O binary format) differentiates between shared libraries, i.e., common code shared between multiple applications, and loadable modules, i.e., code that is programmatically loaded at runtime by an application. On most UNIXen, you can treat a plugin as a library to link against, or, at runtime, dynamically load a shared library. On Mac OS X there is a clear delineation between the two (MH_DYLIB for "shared libraries" and MH_BUNDLE for "plugins"), and (with exceptions) you can't treat one as the other.
Linking Libraries
To create libraries on Mac OS X, generally you should not call the linker directly. Instead, use "gcc" (for c or objective c code), or "g++" (for c++ code) and it will determine what it needs to do to link your code. GCC will pass ld options through to the linker, although if you're using GNU libtool you may need to escape some options using -Wl,<option> for things to get passed through correctly.
An example of linking a dylib (or "shared library"):
gcc -dynamiclib -o libmylib.dylib objectfile1.o objectfile2.o -install_name /usr/local/lib/libmylib.dylib
An example of linking a bundle (or "plugin"):
gcc -bundle -o mybundle.bundle objectfile1.o objectfile2.o -undefined dynamic_lookup
Note that -undefined dynamic_lookup is an OS X 10.3 and later specific feature, and thus requires the MACOSX_DEPLOYMENT_TARGET environment variable to be set to 10.3. In earlier releases of OS X, you must either use -bundle_loader and link to all libraries and frameworks that the executable loader links to (not as extensible as a dynamic_lookup bundle), or use -flat_namespace -undefined suppress (not recommended, flat namespaces can have bad side-effects; see Two-Level Namespaces below).
The same example using GNU libtool would look like this:
glibtool --mode=link gcc -o libmylib.la -rpath /usr/local/lib objectfile1.lo objectfile2.lo glibtool --mode=link gcc -o mybundle.la -module -rpath /usr/local/lib objectfile1.lo objectfile2.lo
Note that the GNU libtool form of bundle ("plugin") creation will actually use the extension ".so" instead of ".bundle". The Mac OS X linker enforces no naming conventions for bundles, and Apple's guidelines have little to say on the issue, so most ported unix apps use the GNU libtool convention of ".so", which is common for other UNIX-like operating systems. Also, depending on the version of GNU libtool you're using, there are any number of quirks that could happen when building libraries and bundles for OS X. We have attempted to document them in the GNU Libtool on Mac OS X section of this wiki. Generally, the newer your GNU libtool, the better.
Two-Level Namespaces
It's possible for more than one library to have a symbol of the same name. In early Mac OS X releases (before 10.1), there was a conflict if more than one library exported a particular name. Since the release of 10.1, Mac OS X has supported "two level" object files. These object files use both the source library (a "namespace") and the name of the symbol for dynamic references, thus eliminating the possibility of conflicts. Since Mac OS X 10.2, two level namespaces have been the default.
Note that this problem is still present in other dynamic linkers and flat namespaced programming languages (C, in particular), so most portable software attempts to workaround this deficiency at a higher level than the linker by manging the symbol names. In any case, two-level namespaces are highly recommended, as flat namespaces do NOT behave identially to the flat namespaces of other popular linkers. Most importantly: the first definition of a symbol is used, rather than the last, which can cause serious problems with plugin loading.
[This wiki page was started by Benjamin Reed based on documentation all over the net, as well as tips picked up on #fink and #opendarwin on irc .]
