Workaround for a msvc 7.1 & 8.0 bug surfaced in the boost 1.35 release part II
Hi all, Boost 1.35 triggers msvc 7.1 & 8.0 to export a local type named CRITICAL_SECTION declared in detail/lwm_win32_cs.hpp into the global namespace. This causes 'ambiguous identifier' compiler errors upon attempts to use (the global Windows type) CRITICAL_SECTION. Please refer to; [boost.pool] Workaround for a msvc 7.1 & 8.0 bug surfaced in the boost 1.35 release 4/8/2008 3:52 PM and; Changeset link: http://svn.boost.org/trac/boost/changeset/44480 Above fixes problems caused by usage of CRITICAL_SECTION in Boost itself namely in pool/detail/mutex.hpp. However usage of CRITICAL_SECTION outside Boost still gives problems. For example; #include <boost/archive/text_iarchive.hpp> typedef int CRITICAL_SECTION; CRITICAL_SECTION cs; or (real live case); #include <boost/archive/text_iarchive.hpp> #include <atlcore.h> Results in 'ambiguous identifier' compiler errors. I attached a patch of detail/lwm_win32_cs.hpp that fixes this. Note that; 1. a real solution to the problem would be to alter Boost such that the VS compiler bug is no longer triggered. 2. more local types, other then CRITICAL_SECTION, may have the same problem. Kind regards, Okko Willeboordse Index: lwm_win32_cs.hpp =================================================================== --- lwm_win32_cs.hpp (revision 45417) +++ lwm_win32_cs.hpp (working copy) @@ -17,8 +17,15 @@ // http://www.boost.org/LICENSE_1_0.txt) // +// 'CRITICAL_SECTION' type has been renamed here due to a MSVC 7.0, 7.1 & 8.0 +// bug causing this local type to be exported into the global namespace, later +// causing 'ambiguous identifier' compiler errors if anyone attempts to use the +// global Windows CRITICAL_SECTION type without using its fully qualified name +// '::CRITICAL_SECTION'. + #ifdef BOOST_USE_WINDOWS_H # include <windows.h> +typedef CRITICAL_SECTION CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG; #endif namespace boost @@ -29,7 +36,7 @@ #ifndef BOOST_USE_WINDOWS_H -struct CRITICAL_SECTION +struct CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG { struct critical_section_debug * DebugInfo; long LockCount; @@ -43,10 +50,10 @@ #endif }; -extern "C" __declspec(dllimport) void __stdcall InitializeCriticalSection(CRITICAL_SECTION *); -extern "C" __declspec(dllimport) void __stdcall EnterCriticalSection(CRITICAL_SECTION *); -extern "C" __declspec(dllimport) void __stdcall LeaveCriticalSection(CRITICAL_SECTION *); -extern "C" __declspec(dllimport) void __stdcall DeleteCriticalSection(CRITICAL_SECTION *); +extern "C" __declspec(dllimport) void __stdcall InitializeCriticalSection(CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG *); +extern "C" __declspec(dllimport) void __stdcall EnterCriticalSection(CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG *); +extern "C" __declspec(dllimport) void __stdcall LeaveCriticalSection(CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG *); +extern "C" __declspec(dllimport) void __stdcall DeleteCriticalSection(CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG *); #endif // #ifndef BOOST_USE_WINDOWS_H @@ -54,7 +61,7 @@ { private: - CRITICAL_SECTION cs_; + CRITICAL_SECTION_RENAMED_TO_AVOID_VS_BUG cs_; lightweight_mutex(lightweight_mutex const &); lightweight_mutex & operator=(lightweight_mutex const &);
Okko Willeboordse:
Boost 1.35 triggers msvc 7.1 & 8.0 to export a local type named CRITICAL_SECTION declared in detail/lwm_win32_cs.hpp into the global namespace. This causes 'ambiguous identifier' compiler errors upon attempts to use (the global Windows type) CRITICAL_SECTION.
I renamed the local CRITICAL_SECTION to critical_section to avoid this ambiguity. See revision 45545.
Hi Peter.
I renamed the local CRITICAL_SECTION to critical_section to avoid this ambiguity. See revision 45545.
Could you also add the comment from the original patch to explain why this has been done? Since there are no tests prepared that would catch this if it ever regressed... Best regards, Jurko Gospodnetić
Hi again.
I renamed the local CRITICAL_SECTION to critical_section to avoid this ambiguity. See revision 45545.
Could you also add the comment from the original patch to explain why this has been done? Since there are no tests prepared that would catch this if it ever regressed...
Also... the renamed class name as used in the original patch seemed clearer since Visual C++ still has a bug with exposing this identified in the global namespace... and 'critical_section' seems much more likely to cause problems than critical_section__whatever_we_write_here_as_an_explanation. Best regards, Jurko Gospodnetić
Jurko Gospodnetić:
Also... the renamed class name as used in the original patch seemed clearer since Visual C++ still has a bug with exposing this identified in the global namespace... and 'critical_section' seems much more likely to cause problems than critical_section__whatever_we_write_here_as_an_explanation.
The bug appears to import all boost::detail identifiers into the global namespace, not just critical_section. It's not reasonable to change them all. A better way to deal with the problem would be to just remove the offending "using namespace boost::detail;" line from boost/serialization/detail/shared_count_132.hpp. It's even guarded for Borland. Note also the "using namespace boost;" in the same header, it imports all boost identifiers as well, and it's definitely not reasonable to change these to contain an "explanation" suffix.
Jurko Gospodnetić:
Also... the renamed class name as used in the original patch seemed clearer since Visual C++ still has a bug with exposing this identified in the global namespace... and 'critical_section' seems much more likely to cause problems than critical_section__whatever_we_write_here_as_an_explanation.
The bug appears to import all boost::detail identifiers into the global namespace, not just critical_section. It's not reasonable to change them all. A better way to deal with the problem would be to just remove the offending "using namespace boost::detail;" line from boost/serialization/detail/shared_count_132.hpp. It's even guarded for Borland. Note also the "using namespace boost;" in the same header, it imports all boost identifiers as well, and it's definitely not reasonable to change these to contain an "explanation" suffix.
No interest? Robert? Jurko?
I've done exactly this - I don't know if I checked it yet. It only requred a couple of changes in the body of shared_count so I'm fine with this final workaround. Robert Ramey Peter Dimov wrote: A better way to deal with the problem would be to
just remove the offending "using namespace boost::detail;" line from boost/serialization/detail/shared_count_132.hpp.
Robert Ramey:
I've done exactly this - I don't know if I checked it yet. It only requred a couple of changes in the body of shared_count so I'm fine with this final workaround.
No, it doesn't seem to be checked in.
Peter Dimov wrote: A better way to deal with the problem would be to
just remove the offending "using namespace boost::detail;" line from boost/serialization/detail/shared_count_132.hpp.
Hi Peter.
Also... the renamed class name as used in the original patch seemed clearer since Visual C++ still has a bug with exposing this identified in the global namespace... and 'critical_section' seems much more likely to cause problems than critical_section__whatever_we_write_here_as_an_explanation. The bug appears to import all boost::detail identifiers into the global namespace, not just critical_section. It's not reasonable to change them all. A better way to deal with the problem would be to just remove the offending "using namespace boost::detail;" line from boost/serialization/detail/shared_count_132.hpp. It's even guarded for Borland. Note also the "using namespace boost;" in the same header, it imports all boost identifiers as well, and it's definitely not reasonable to change these to contain an "explanation" suffix.
No interest? Robert? Jurko?
Oh, sorry... I have not replied because I agree with you and could not think of anything useful to give back to the conversation. :-) I guess I should have nodded... As to the actual shared_count_132.hpp change... If someone can do it - I am all for it... I guess I am just too much of a coward to do it myself. :-)) Fear of way too many undocumented relations to other code that I have no way of testing... and of not having enough time to properly deal with all the feedback/anger resulting from the change. :-) I would be happy to review it though... Best regards, Jurko Gospodnetić
Hello, I just tried to upgrade to boots 1.35 Compiling boost was OK. Compiling my project in debug mode is OK. but compiling the project in release mode failed always. Driver.cpp C:\Boost\include\boost-1_35\boost\format\feed_args.hpp(203) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2708) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information Trying to disable some compiler switches don't solve my problem. compiler switches: /O2 /G7 /GA /I "E:\Devel\TRIOPTICS\EFL-Production2\\" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /D "NO_DEPRECATED" /D "NO_ATL_REG_EXP" /D "_NO_DEFAULT_PARAMETER" /D "_BOOST" /D "_AFXDLL" /D "_MBCS" /FD /EHsc /MD /Zc:forScope /GR /Yu"stdafx.h" /Fp"Release/build/MTF-Field.pch" /Fx /FAcs /Fa"Release/build/" /Fo"Release/build/" /Fd"Release/build/vc70.pdb" /FR"Release/build/" /W3 /WX /nologo /c /Wp64 /TP after some test I found that the switch /FR"Release/build/" cause the Problem. Do any one know this Problem ? bye Bernd -- Bernd Martin Wollny TRIOPTICS GmbH - www.trioptics.com b.wollny@trioptics.com Hafenstrasse 39, 22880 Wedel/GERMANY Software Designer Geschäftsführer: Dipl.-Ing. Eugen Dumitrescu phone / fax: +49 (0)4103 18006-26 /-20 Amtsgericht Pinneberg HRB 3215 All E-Mails from bm.wollny@trioptics.com are digital signed. If you get a unsigned E-Mail, this E-Mail are a fake. Look at http://www.gnupg.org .
I have come across many similar error messages. In most cases turning off precompiled headers solves the problem. In my case it appeared to be a bug with the implementation of namespaces in Visual C++. Try turning off precompiled headers for this file. HTH, Neil Groves On Wed, Jun 18, 2008 at 1:07 PM, Bernd Martin Wollny < bm.wollny@trioptics.com> wrote:
Hello,
I just tried to upgrade to boots 1.35 Compiling boost was OK. Compiling my project in debug mode is OK. but compiling the project in release mode failed always.
Driver.cpp C:\Boost\include\boost-1_35\boost\format\feed_args.hpp(203) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2708) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information
Trying to disable some compiler switches don't solve my problem.
compiler switches: /O2 /G7 /GA /I "E:\Devel\TRIOPTICS\EFL-Production2\\" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /D "NO_DEPRECATED" /D "NO_ATL_REG_EXP" /D "_NO_DEFAULT_PARAMETER" /D "_BOOST" /D "_AFXDLL" /D "_MBCS" /FD /EHsc /MD /Zc:forScope /GR /Yu"stdafx.h" /Fp"Release/build/MTF-Field.pch" /Fx /FAcs /Fa"Release/build/" /Fo"Release/build/" /Fd"Release/build/vc70.pdb" /FR"Release/build/" /W3 /WX /nologo /c /Wp64 /TP
after some test I found that the switch /FR"Release/build/" cause the Problem.
Do any one know this Problem ?
bye Bernd
-- Bernd Martin Wollny TRIOPTICS GmbH - www.trioptics.com b.wollny@trioptics.com Hafenstrasse 39, 22880 Wedel/GERMANY Software Designer Geschäftsführer: Dipl.-Ing. Eugen Dumitrescu phone / fax: +49 (0)4103 18006-26 /-20 Amtsgericht Pinneberg HRB 3215
All E-Mails from bm.wollny@trioptics.com are digital signed. If you get a unsigned E-Mail, this E-Mail are a fake. Look at http://www.gnupg.org .
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Neil Groves wrote:
I have come across many similar error messages. In most cases turning off precompiled headers solves the problem. In my case it appeared to be a bug with the implementation of namespaces in Visual C++.
Try turning off precompiled headers for this file.
HTH, Neil Groves
Hi Neil, I have seen, in older posts, that the disabling of "precompiled headers" should solve the Problem. But only the disabling of /FR "Microsoft Browse Information File" solve the Problem. And this is very strange. I am using .Net 2003 bye Bernd
On Wed, Jun 18, 2008 at 1:07 PM, Bernd Martin Wollny < bm.wollny@trioptics.com> wrote:
Hello,
I just tried to upgrade to boots 1.35 Compiling boost was OK. Compiling my project in debug mode is OK. but compiling the project in release mode failed always.
Driver.cpp C:\Boost\include\boost-1_35\boost\format\feed_args.hpp(203) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2708) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information
Trying to disable some compiler switches don't solve my problem.
compiler switches: /O2 /G7 /GA /I "E:\Devel\TRIOPTICS\EFL-Production2\\" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /D "NO_DEPRECATED" /D "NO_ATL_REG_EXP" /D "_NO_DEFAULT_PARAMETER" /D "_BOOST" /D "_AFXDLL" /D "_MBCS" /FD /EHsc /MD /Zc:forScope /GR /Yu"stdafx.h" /Fp"Release/build/MTF-Field.pch" /Fx /FAcs /Fa"Release/build/" /Fo"Release/build/" /Fd"Release/build/vc70.pdb" /FR"Release/build/" /W3 /WX /nologo /c /Wp64 /TP
after some test I found that the switch /FR"Release/build/" cause the Problem.
Do any one know this Problem ?
bye Bernd
AMDG Bernd Martin Wollny wrote:
I just tried to upgrade to boots 1.35 Compiling boost was OK. Compiling my project in debug mode is OK. but compiling the project in release mode failed always.
What version of msvc? In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
Bernd Martin Wollny wrote:
I just tried to upgrade to boots 1.35 Compiling boost was OK. Compiling my project in debug mode is OK. but compiling the project in release mode failed always.
What version of msvc?
In Christ, Steven Watanabe
Sorry I forget to write the compiler version. I am using .Net 2003 bye Bernd
participants (7)
-
Bernd Martin Wollny -
Jurko Gospodnetić -
Neil Groves -
Okko Willeboordse -
Peter Dimov -
Robert Ramey -
Steven Watanabe