Boost Users :
Subject: [Boost-users] MSVC _SECURE_SCL causes ABI change, ODR violation - mangle library names?
From: Jean-Francois Bastien (jfbastien_at_[hidden])
Date: 2008-10-10 10:03:22
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
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
There's already a Trac issue for this:
Could we reach a consensus on adding this to the library name mangling?
Is it too late for 1.37.0?
msvc toolset addition stl-security-theater
High Cost of MS "Safe" STL for Release Builds
System: error_code.cpp #definesmacroswithoutchecking if already defined
What plans to handle _SCEURE_SCL in the boost build system?
Intel compiler - does anyone care?
bjam define=_SECURE_SCL shows no effect
Bug/Incompatibility: Visual C++ 2005 checkediteratorslead to major
vc 8 secure stl/runtime and boost
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net