Re: [Boost-users] [program options] access violation with _SECURE_SCL turned off

Peter Bartlett schrieb:

Quoting klaus triendl :

...

Juergen Hunold schrieb:

...

Of course, re-compile Boost in release mode with _SECURE_SCL=0. The developer list has two or three threads about a general solution, including different name mangling. Just search the archives...

I didn't build boost myself, until now... Thanks for your answer, that helped me a lot!

I naively built boost with a D_SECURE_SCL=0 on the bjam command line recently. It became the source of crashes even more confusing than those the original poster found. I believe, but never truly determined, that the define was being propagated to some but not all build targets.

Hmm, I've turned the macro off on the commandline with the bjam built-in option: define=_SECURE_SCL=0

If you are going down this route, I recommend you investigate the feature approach of Thorsten Ottosen : http://article.gmane.org/gmane.comp.lib.boost.devel/185987 . I understand it avoids these problems but haven't yet had time to confirm that myself.

_CRT_NONSTDC_NO_DEPRECATE doesn't have to do anything with the *ms secure* functions but only deprecate posix named functions that have an iso c++ named variant. And as far as I understand from Stephan T Lavevej's blog (comment #2 at http://blogs.msdn.com/vcblog/archive/2007/02/26/stl-destructor-of-bugs.aspx) only _SECURE_SCL (and _HAS_ITERATOR_DEBUGGING) cause a different ABI. Klaus