vc8 failure in boost_python-dll-vc-8_0
There is single error at http://tinyurl.com/9u6nd : use_ansi.h(49) : fatal error C1189: #error : You have included some C++/C library header files with _DEBUG defined and some with _DEBUG not defined. This will not work correctly. Please have _DEBUG set or clear consistently. ... which renders whole Boost.Python unusable under vc8. It looks as if parts of the library were build with DEBUG macro set, and other parts without it (which might lead to ODR violation). I do not know if this is jamfile problem or something else. Compiler being used is RTM version. Dave, do you need help tracing the problem? B.
"Bronek Kozicki" <brok@rubikon.pl> writes:
There is single error at http://tinyurl.com/9u6nd :
use_ansi.h(49) : fatal error C1189: #error : You have included some C++/C library header files with _DEBUG defined and some with _DEBUG not defined. This will not work correctly. Please have _DEBUG set or clear consistently.
... which renders whole Boost.Python unusable under vc8.
Strange; the latest Beta I have is working fine for me.
It looks as if parts of the library were build with DEBUG macro set, and other parts without it (which might lead to ODR violation). I do not know if this is jamfile problem or something else. Compiler being used is RTM version.
It is probably not a problem at all, technically. See http://www.boost.org/libs/python/doc/building.html#variants. On the other hand, I don't know what to do to suppress the error. And since Microsoft hasn't sent me the VS 2005 release, I can't test Boost against it :(
Dave, do you need help tracing the problem?
I guess so. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
It is probably not a problem at all, technically. See http://www.boost.org/libs/python/doc/building.html#variants.
On the other hand, I don't know what to do to suppress the error. And since Microsoft hasn't sent me the VS 2005 release, I can't test Boost against it :(
do you have MSDN subscription? If so, you may download it. You do not need whole ~3GB, much smaller Visual C++ 2005 Express is enough (but you will need to pull Platform SDK, though).
Dave, do you need help tracing the problem?
I guess so.
Apparently problem is wider and applies to other libraries as well. I just tried building whole boost 1.31.1 RC by hand on MSVC8: bjam.exe "-sTOOLS=vc-8_0" "-sBUILD=release debug <runtime-link>dynamic <threading>multi <debug-symbols>off" stage and no dll files were created. I checked bjam log, and found that linker fails with message: error LNK2001: unresolved external symbol ___CxxFrameHandler3 It is possible that it's problem with my setup, or that toolset vc-8_0 is not compatible with Visual C++ 2005 Express. Now I'm trying to build boost 1.31.1 RC again, this time with -d2 option. B.
"Bronek Kozicki" <brok@rubikon.pl> writes:
David Abrahams <dave@boost-consulting.com> wrote:
It is probably not a problem at all, technically. See http://www.boost.org/libs/python/doc/building.html#variants.
On the other hand, I don't know what to do to suppress the error. And since Microsoft hasn't sent me the VS 2005 release, I can't test Boost against it :(
do you have MSDN subscription?
No. I've been using compilers MS has donated for the purpose of Boost testing. But as I said, I don't have the release version. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 08:06 2005-11-02, David Abrahams wrote:
"Bronek Kozicki" <brok@rubikon.pl> writes:
David Abrahams <dave@boost-consulting.com> wrote:
It is probably not a problem at all, technically. See http://www.boost.org/libs/python/doc/building.html#variants.
On the other hand, I don't know what to do to suppress the error. And since Microsoft hasn't sent me the VS 2005 release, I can't test Boost against it :(
do you have MSDN subscription?
No. I've been using compilers MS has donated for the purpose of Boost testing. But as I said, I don't have the release version.
it seems to me that the error message is rather explicit. now HOW the system has managed to get some include files included with _DEBUG defined and others NOT in a compilation unit, I don't know. BTW, I've run the regression tests on the RTM, and the same error shows up. (see results for RudbekAssociates)
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
it seems to me that the error message is rather explicit. now HOW the system has managed to get some include files included with _DEBUG defined and others NOT in a compilation unit, I don't know.
culprit is #undef _DEBUG , line 25 in boost/python/wrap_python.hpp, and about 120 lines later #define _DEBUG. However, disabling this line (and #define later) will NOT solve the problem, it will just move it, as linker will want to link against python24_d.lib that is not installed by default with python. Now I think that maybe defining _CRT_NOFORCE_MANIFEST before including any python headers (eg. just after #undef _DEBUG) could solve the problem without too many side effects. B.
Bronek Kozicki <brok@rubikon.pl> writes:
Victor A. Wagner Jr. wrote:
it seems to me that the error message is rather explicit. now HOW the system has managed to get some include files included with _DEBUG defined and others NOT in a compilation unit, I don't know.
culprit is #undef _DEBUG , line 25 in boost/python/wrap_python.hpp, and about 120 lines later #define _DEBUG.
However, disabling this line (and #define later) will NOT solve the problem, it will just move it, as linker will want to link against python24_d.lib that is not installed by default with python.
Now I think that maybe defining _CRT_NOFORCE_MANIFEST before including any python headers (eg. just after #undef _DEBUG) could solve the problem without too many side effects.
Do you understand what _CRT_NOFORCE_MANIFEST really does? -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 14:59 2005-11-03, you wrote:
Bronek Kozicki <brok@rubikon.pl> writes:
Victor A. Wagner Jr. wrote:
it seems to me that the error message is rather explicit. now HOW the system has managed to get some include files included with _DEBUG defined and others NOT in a compilation unit, I don't know.
culprit is #undef _DEBUG , line 25 in boost/python/wrap_python.hpp, and about 120 lines later #define _DEBUG.
However, disabling this line (and #define later) will NOT solve the problem, it will just move it, as linker will want to link against python24_d.lib that is not installed by default with python.
Now I think that maybe defining _CRT_NOFORCE_MANIFEST before including any python headers (eg. just after #undef _DEBUG) could solve the problem without too many side effects.
Do you understand what _CRT_NOFORCE_MANIFEST really does?
I do _not_
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
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.
"Bronek Kozicki" <brok@rubikon.pl> writes:
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.
What kind of bug. Is it just technically wrong, or are there consequences? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Bronek Kozicki" <brok@rubikon.pl> writes:
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?
Unfortunately the line above is causing this to break with Visual Studio 8 Express edition. That header doesn't exist after installing the Core Windows part of the PSDK. How did you come up with this list? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
# include <basetsd.h> ^^^^^^^^^
this header (as the only one #included here) belongs to Platform SDK. It should be in "C:\Program Files\Microsoft Platform SDK\include" . It certainly belongs to Microsoft Windows Core SDK - April 2005 edition. Could you pls. check this on your computer? If you have this file, did you added the directory to INCLUDE? To which one? If you have VC80_ROOT set, you also need to have VS80COMNTOOLS set, as it is used by %VC80_ROOT%\vcvarsall.bat , and the Platform SDK\include directory should be *manually* added to %VS80COMNTOOLS%vsvars32.bat If you have MSVCDir set, then you just need to have this directory in your INCLUDE .
Unfortunately the line above is causing this to break with Visual Studio 8 Express edition. That header doesn't exist after installing the Core Windows part of the PSDK.
I tested it on Visual C++ 2005 Express with Platform SDK April 2005 edition.
How did you come up with this list?
I called vc8 compiler with /P option on libs\python\src\numeric.cpp to see preprocessor output. I also added #error directive in boost\python\detail\wrap_python.hpp just after # define _DEBUG to cut irrelevant output. Then I filtered all headers ("#line 1" in preprocessor output) that are not from boost nor python. B.
Bronek Kozicki <brok@rubikon.pl> writes:
David Abrahams wrote:
# include <basetsd.h> ^^^^^^^^^
this header (as the only one #included here) belongs to Platform SDK. It should be in "C:\Program Files\Microsoft Platform SDK\include" .
Ah, there it is.
It certainly belongs to Microsoft Windows Core SDK - April 2005 edition. Could you pls. check this on your computer?
It is.
If you have this file, did you added the directory to INCLUDE?
Nope. I've never had to modify a stock VS installation in order to get things to work before. It doesn't appear that
To which one? If you have VC80_ROOT set,
I don't; I used the default installation location.
you also need to have VS80COMNTOOLS set, as it is used by %VC80_ROOT%\vcvarsall.bat , and the Platform SDK\include directory should be *manually* added to %VS80COMNTOOLS%vsvars32.bat
Okay, I edited c:/Program Files/Microsoft Visual Studio 8/Common7/Tools/vsvars32.bat to do that. It's a big surprise to me that the SDK installer doesn't take care of that stuff for me. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
you also need to have VS80COMNTOOLS set, as it is used by %VC80_ROOT%\vcvarsall.bat , and the Platform SDK\include directory should be *manually* added to %VS80COMNTOOLS%vsvars32.bat
Okay, I edited c:/Program Files/Microsoft Visual Studio 8/Common7/Tools/vsvars32.bat to do that. It's a big surprise to me that the SDK installer doesn't take care of that stuff for me.
<put my MVP hat on> Martyn do you think that documentation on http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/ could be updated to mention this file? We could then add reference there from http://www.boost.org/tools/build/v1/vc-8_0-tools.html . This info would be relevant to anyone wishing to build Win32 apps from the command line, not only boost users. <MVP hat off> We could update toolset description to mention it. B.
David Abrahams <dave@boost-consulting.com> writes:
Okay, I edited c:/Program Files/Microsoft Visual Studio 8/Common7/Tools/vsvars32.bat to do that. It's a big surprise to me that the SDK installer doesn't take care of that stuff for me.
Now I'm seeing that it can't find uuid.lib vc-Link c:\tmp\build\bin\boost\libs\python\test\map_indexing_suite_ext.pyd\vc-8_0\debug\threading-multi\map_indexing_suite_ext.pyd c:\tmp\build\bin\boost\libs\python\test\map_indexing_suite_ext.pyd\vc-8_0\debug\threading-multi\map_indexing_suite_ext.lib LINK : fatal error LNK1104: cannot open file 'uuid.lib' Any clues about that one? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Now I'm seeing that it can't find uuid.lib
Sorry, I forgot to mention that you also need to append C:\Program Files\Microsoft Platform SDK\Lib to LIB in the same location where you updated INCLUDE B. -- Bronek Kozicki brok@spamcop.net http://b.kozicki.pl/
On 11/2/05, Bronek Kozicki <brok@rubikon.pl> wrote: Apparently problem is wider and applies to other libraries as well. I
just tried building whole boost 1.31.1 RC by hand on MSVC8: bjam.exe "-sTOOLS=vc-8_0" "-sBUILD=release debug <runtime-link>dynamic <threading>multi <debug-symbols>off" stage
I just build the latest CVS HEAD and RC_1_33_0 with these same options (well, only release not debug) and all worked flawlessly modulo the new compiler warnings emitted by VS2005. I think it may be a problem with either your setup or VC++ 2005 Express. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein <caleb.epstein@gmail.com> wrote:
On 11/2/05, Bronek Kozicki <brok@rubikon.pl> wrote:
Apparently problem is wider and applies to other libraries as well. I
just tried building whole boost 1.31.1 RC by hand on MSVC8: bjam.exe "-sTOOLS=vc-8_0" "-sBUILD=release debug <runtime-link>dynamic <threading>multi <debug-symbols>off" stage
I just build the latest CVS HEAD and RC_1_33_0 with these same options (well, only release not debug) and all worked flawlessly modulo the new compiler warnings emitted by VS2005. I think it may be a problem with either your setup or VC++ 2005 Express.
Do you have RTM (build 14.00.50727.42) version of vc8? Indeed, the problem that none of boost DLLs were built was setup error, fixed now. It did not apply to regression tests, anyway (it was only problem with my manual build). However, debug build of python DLL was still failing. I verified that this error goes away if additional define _CRT_NOFORCE_MANIFEST is passed to compiler. I tweaked vc-8_0-tools.jam on my local computer to define this preprocessor symbol (just added line "flags vc-8_0 C++FLAGS : -D_CRT_NOFORCE_MANIFEST ;"), however I have no idea why there was an error in the first place and if this fix does not break anything else. After this (local) fix the only problems building boost I have are two compiler errors in boost_signals (see separate message). Anyone knows what _CRT_NOFORCE_MANIFEST means and/or is wiling to apply the fix to CVS? B.
On 11/2/05, Bronek Kozicki <brok@rubikon.pl> wrote:
Do you have RTM (build 14.00.50727.42) version of vc8?
Yes: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. Indeed, the problem that none of boost DLLs were built was setup error,
fixed now. It did not apply to regression tests, anyway (it was only problem with my manual build). However, debug build of python DLL was still failing.
I don't have Python installed. Sorry. Anyone knows what _CRT_NOFORCE_MANIFEST means and/or is wiling to apply
the fix to CVS?
Can't find any reference to that in the online help, but I guess you know that :) Where did you dig that option up? -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
On 11/2/05, Bronek Kozicki <brok@rubikon.pl> wrote: Anyone knows what _CRT_NOFORCE_MANIFEST means and/or is wiling to apply
the fix to CVS?
Can't find any reference to that in the online help, but I guess you know that :) Where did you dig that option up?
The VC8 libraries (CRT, ATL and MFC) will add pragmas that add manifest entries (Windows XP side-by-side DLL installs) for that library by default. VC8 will then use that information to embed the manifest into the executable. _CRT_NOFORCE_MANIFEST prevents these manifests being automatically added. NOTE: I currently have VC8 beta 2 (looking to upgrade shortly), and that uses _STL_NOFORCE_MANIFEST (see the use_ansi.h header file). - Reece
"Bronek Kozicki" <brok@rubikon.pl> writes:
Caleb Epstein <caleb.epstein@gmail.com> wrote:
On 11/2/05, Bronek Kozicki <brok@rubikon.pl> wrote:
Apparently problem is wider and applies to other libraries as well. I
just tried building whole boost 1.31.1 RC by hand on MSVC8: bjam.exe "-sTOOLS=vc-8_0" "-sBUILD=release debug <runtime-link>dynamic <threading>multi <debug-symbols>off" stage
I just build the latest CVS HEAD and RC_1_33_0 with these same options (well, only release not debug) and all worked flawlessly modulo the new compiler warnings emitted by VS2005. I think it may be a problem with either your setup or VC++ 2005 Express.
Do you have RTM (build 14.00.50727.42) version of vc8?
Indeed, the problem that none of boost DLLs were built was setup error, fixed now. It did not apply to regression tests, anyway (it was only problem with my manual build). However, debug build of python DLL was still failing.
I verified that this error goes away if additional define _CRT_NOFORCE_MANIFEST is passed to compiler. I tweaked vc-8_0-tools.jam on my local computer to define this preprocessor symbol (just added line "flags vc-8_0 C++FLAGS : -D_CRT_NOFORCE_MANIFEST ;"), however I have no idea why there was an error in the first place and if this fix does not break anything else. After this (local) fix the only problems building boost I have are two compiler errors in boost_signals (see separate message).
Anyone knows what _CRT_NOFORCE_MANIFEST means and/or is wiling to apply the fix to CVS?
I'm very reluctant to mess with the manifest stuff. I was told personally by Martyn Lovell of Microsoft that it was necessary and he helped me to get it right in our Boost.Python build. I don't really understand the manifest stuff at a deep level, so the fact that you found -D_CRT_NOFORCE_MANIFEST suppresses the problem you're seeing doesn't lead me to the conclusion that it's really a "fix." -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
I'm very reluctant to mess with the manifest stuff. I was told personally by Martyn Lovell of Microsoft that it was necessary and he helped me to get it right in our Boost.Python build. I don't really understand the manifest stuff at a deep level, so the fact that you found -D_CRT_NOFORCE_MANIFEST suppresses the problem you're seeing doesn't lead me to the conclusion that it's really a "fix."
Well, I just passed some idea that might work (and might damage something else as well). I will look further into it tomorrow. Maybe some more appropriate way of dealing with this can be devised . Maybe you could ask Martyn to install Python (eg. from activestate) and run regression test to see the problem? B.
participants (1)
-
Bronek Kozicki -
Bronek Kozicki -
Caleb Epstein -
David Abrahams -
Reece Dunn -
Victor A. Wagner Jr.