David Abrahams <dave@boost-consulting.com> wrote:
Do you understand what _CRT_NOFORCE_MANIFEST really does?
No :-( I see this has been raised already on boost-testing http://lists.boost.org/boost-testing/2005/08/1920.php As it turned out in discussion with Martyn Lovell, mixing C headers with _DEBUG and without this symbol *is* a bug, at least in Visual C++, and this is exactly what we are doing in wrap_python.hpp . We have a block of code where we #undef _DEBUG, then #include Python headers (which in turn #include some C headers) and several C headers too, and then we #define _DEBUG back. Any following #include of C header will trigger the error in vc8, and is a (silent one!) source of problems in previous versions of MSVC. What I think we could do is to #include all required C headers *before* #undef _DEBUG, and depend on their own inclusion guards (or #pragma once) to prevent them being parsed in the following part of the code where _DEBUG is #undef-ed. This means modyfing part of wrap_python.hpp to something like (I will test it right away): #ifdef _DEBUG # ifndef BOOST_DEBUG_PYTHON # ifdef _MSC_VER # include <io.h> # include <stdio.h> # include <limits.h> # include <float.h> # include <basetsd.h> # include <string.h> # include <errno.h> # include <stdlib.h> # include <unistd.h> # include <stddef.h> # include <assert.h> // possibly more headers, to be verified # endif # undef _DEBUG // Don't let Python force the debug library # define DEBUG_UNDEFINED_FROM_WRAP_PYTHON_H # endif #endif // No changes below this line Dave, what do you think? As it currently stands out (without this or similar fix) we are actually injecting bug into all MSVC projects (not only vc8 - it's only protection built into vc8 headers that exposed the problem) that happen to #include wrap_python.hpp . I think this is showstopper for 1.33.1, even though regression tests currently are all green for other versions of MSVC. B.