The _SECURE_SCL macro in Visual Studio's (Dinkumware's) STL changes the ABI for standard types, which causes silent ODR violations when Boost static libraries and the main program linking with them don't define this macro the same way. This problem manifests itself as runtime crashes. There's been discussion before (see links at the end) to solve this by using different library names in the build system to distinguish different ABIs. The discussions brought up issues: - _SECURE_SCL implies a performance cost. - _SECURE_SCL might not be conformant with the complexity requirements (no clear conclusion was reached on this). - Should the compiler's default behaviour be Boost's default (i.e. _SECURE_SCL isn't defined)? - The Windows version of the Intel compiler has a bug around partial function template ordering which can be solved by defining _SECURE_SCL to 0. There's already a Trac issue for this: http://svn.boost.org/trac/boost/ticket/2086 Could we reach a consensus on adding this to the library name mangling? Is it too late for 1.37.0? Thanks, JF References: msvc toolset addition stl-security-theater http://lists.boost.org/boost-build/2008/09/index.php#20072 High Cost of MS "Safe" STL for Release Builds http://lists.boost.org/boost-build/2008/04/18828.php System: error_code.cpp #definesmacroswithoutchecking if already defined http://lists.boost.org/boost-build/2008/04/18754.php What plans to handle _SCEURE_SCL in the boost build system? http://lists.boost.org/Archives/boost/2008/04/index.php#136481 Intel compiler - does anyone care? http://lists.boost.org/Archives/boost/2008/01/index.php#132079 bjam define=_SECURE_SCL shows no effect http://lists.boost.org/boost-users/2007/05/index.php#27928 Bug/Incompatibility: Visual C++ 2005 checkediteratorslead to major crashes http://lists.boost.org/Archives/boost/2006/06/index.php#106415 vc 8 secure stl/runtime and boost http://lists.boost.org/boost-users/2005/12/index.php#15843