[CMake] Darwin, shared libraries, and undefined symbols

[Zachary Pincus]

Hello,

Some time ago (~CMake 1.6 or 1.8?), the Modules/Platform/Darwin.cmake 
file defined
	CMAKE_SHARED_MODULE_CREATE_C_FLAGS
to contain
	-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
	-bundle

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,

Zach Pincus

Department of Biochemistry and Program in Biomedical Informatics
Stanford University School of Medicine