Hi! I'm looking at versions up to at least 1.37, and in python/detail/config.hpp, I find found some code that is currently in my way, because I'm not sure what it should do. I'm talking about the following few lines: // backwards compatibility: #ifdef BOOST_PYTHON_STATIC_LIB # define BOOST_PYTHON_STATIC_LINK # elif !defined(BOOST_PYTHON_DYNAMIC_LIB) # define BOOST_PYTHON_DYNAMIC_LIB #endif Notes here: 1. The first macro, BOOST_PYTHON_STATIC_LIB, is undocumented and probably (I'm guessing) an old spelling of BOOST_PYTHON_STATIC_LINK. It is used in some Jamfile.v2s, probably to link with or build a static library. On first view, it's odd that the build system depends on backward code. 2. On second look, you see that BOOST_PYTHON_STATIC_LINK is completely unused and similarly undocumented, in any case defining it is not necessary for Boost itself. 3. The macro BOOST_PYTHON_DYNAMIC_LIB is also of questionable use. It is used in that file to setup auto linking and symbol visibility for a dynamic library, but otherwise it is unused. Actually, compare that to config/user.hpp, which says that you should use either of BOOST_{PYTHON,ALL}_DYN_LINK to get dynamic linking. 4. Speaking about config/user.hpp, there is no documented way to specify static linking. I think some libraries use e.g. the _DLL macro on MS' compiler to default to dynamic linking and otherwise assume static linking. Boost.Python instead assumes dynamic linking when nothing is specified and the only way to get static linking is by defining an otherwise undocumented macro. Suggested resolution: 1. Remove above quoted lines. They have been there since 2002 (SVN revisions 12083, 12146, 13462), and any code relying on undocumented backward compat code for such a long time is broken anyway (yes, sadly, that includes Boost itself sadly). 2. Replace checks for BOOST_PYTHON_DYNAMIC_LIB with checks for the macros documented in config/user.hpp. 3. Document BOOST_{ALL,foo}_STATIC_LINK as guaranteed way to get statically linked libraries in config/user.hpp. 4. Maybe introduce a header config/guess_linkage.hpp which will define BOOST_ALL_STATIC_LINK or BOOST_ALL_DYNAMIC_LINK based on heuristics like e.g. _DLL under win32, unless either of these two is already defined. I think that such heuristics already are in place in some libraries, but they should actually be central. I'd start off with 1-3 and then see what breaks. Step 4 will require that checks are changed so that they look like this: if (ALL_DYN_LINK|FOO_DYN_LINK) && !FOO_STATIC_LINK // use dynamic linking else // use static linking endif instead of just like this: if (ALL_DYN_LINK|FOO_DYN_LINK) // use dynamic linking else // use static linking endif so that the detected default does not override an explicitly set linkage. Comments anyone? Uli