Two-level Namespaces
In Mac OS X 10.0, the dynamic linker merged symbols into a single (flat) namespace. So, if you link against two different libraries that both define the same function, the dynamic linker complains, because the same symbol was defined in both places. This approach prevented collisions that were known at compile time. However, if there wasn’t a conflict at compile time, there is no guarantee that a future version of the library won’t introduce a conflict.
Suppose you linked your application against version 1 of
libfoo and version 1 of
libbar. At the time you compiled your
application, libfoo defined a function called
logerror( )
, and libbar did
not. But when version 2 of libbar came out, it
included a function called logerror( )
. Since the
conflict was not known at compile time, your application
doesn’t expect libbar to
contain this function. If your application happens to load
libbar before libfoo, it
will call libbar’s
logerror( )
method, which is not what you want.
So, Mac OS X 10.1 introduced two-level namespaces, which the compiler
uses by default. (Mac OS X 10.2 does not introduce any changes to
two-level namespaces.) With this feature, you can link against
version 1 of libfoo and
libbar. The linker creates an application that
knows logerror( )
lives in
libfoo. So, even if a future version of
libbar includes a logerror( )
function, your application will know which logerror( )
it should use.
If you want to build an application using a flat namespace, use ...
Get Mac OS X for Unix Geeks now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.