[CMake] Darwin, shared libraries, and undefined symbols
zpincus at stanford.edu
Tue Mar 22 18:23:43 EST 2005
Some time ago (~CMake 1.6 or 1.8?), the Modules/Platform/Darwin.cmake
-bundle -flat_namespace -undefined suppress
This made it so that if, for example, you used CMake and SWIG to
produce a module that python could load, then the linker would not
complain about undefined python symbols in the library. Given the flat
namespace, the dynamic linker would patch these in at runtime.
In the current CMake version, Modules/Platform/Darwin.cmake defines
this variable as only
This implies that -two_level_namespace is enabled because it is the
default. With a two level namespace, any undefined symbols must be
patched in at link time, via e.g. an option on the command line like
-bundle_loader /usr/bin/python. As of OS X 10.1, there's also a
-undefined dynamic_lookup option for two level namespaces (provided
that, arrgh, the MACOSX_DEPLOYMENT_TARGET environment variable is set
to 10.1 or higher).
Anyhow, clearly the -flat_namespace stuff was removed for a good
reason. (the CMake CVS log suggests that it was thought to be a bit of
a hack.) However, now this seems to imply that user CMake files need to
have more hackish platform specific tricks to make sure that the
undefined symbols are handled properly.
So: what is the preferred way to deal with undefined symbols?
Darwin-specific stuff in a CMakeLists file? (And if so, hat stuff?
specifying a bundle_loader? Setting some -undefined handler?) Or is
there a better cross-platform way to deal with making such libraries?
Clearly there is some way because SWIG-wrapped python libs get made
properly in Darwin...
Thanks for any hints,
Department of Biochemistry and Program in Biomedical Informatics
Stanford University School of Medicine
More information about the CMake