I did statically link years ago but then, as you said, new releases of some libraries prevented me from doing this anymore and I needed to link dynamically. I managed to remove the extra preprocessor definitions from my application. I then modified the code to look like test 2 above which works and allows me to continue. Test 3 still causes a crash but I cannot see a reason for it :| On 4 September 2013 13:32, Pekka Seppänen < pekka.seppanen@capricodesystems.com> wrote:
On 4.9.2013 14:43, Patrick Steele wrote:
Hi Pekka, thanks for the help. I tried using _SECURE_SCL=1 and _SECURE_SCL=0 but still got the same crash. I see that other variables currently being used in the debug build of my application are:
<snip>
Well, I'd first try to compile Boost (debug variant) with those very same defines set. Either pass those directly to B2.EXE (define=FLAG=value) or look at BOOST_USER_CONFIG.
If that does not work, then I'd try to ditch all those defines alltogether (just make sure everything is as default as it gets). At least with some debug runtime versions it was impossible to have a dynamically linked runtime and define custom runtime related options at the same time; It would always lead to crashes like the one you're encountering.
It could be, that this limitation still exists and if you'd like to disable some debug features you'll have to static link everything. Of course, this is usually impossible and impractical. Then, your only option is to use release runtime without any optimization options set. That way you'll keep your app both usable (what comes to speed) and somewhat debuggable. It's not that you're able to catch all errors with debug runtime anyway.
-- Pekka
______________________________**_________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/**mailman/listinfo.cgi/boost-**usershttp://lists.boost.org/mailman/listinfo.cgi/boost-users