[config] including typeinfo in dinkumware.hpp when RTTI is disabled
Evidently the only way to currently compile clang on Windows using the VC++ RTL is to compile without RTTI and exception handling in its VC++ emulation ( options -D_HAS_EXCEPTIONS=0 /GR- ). This may be totally unrealistic for Boost. Nonetheless with these compiler options, when the dinkumware.hpp is being used by Boost config, it is including typeinfo and this is causing a problem: c:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\typeinfo(156,10) : error: unknown class name 'exception'; did you mean '_exception'? : public exception Is it realistic in dinkumware.hpp to not include typeinfo if RTTI is not enabled ? Or is it just more realistic to say that compiling Boost libraries with RTTI disabled is not going to work ?
Edward Diener wrote:
Or is it just more realistic to say that compiling Boost libraries with RTTI disabled is not going to work ?
Some libraries, such as SmartPtr and, I believe, Function, are specifically made to work with RTTI disabled (and many do work with exceptions disabled). It's probably your #define that's causing the problem, not /GR-. Exceptions under VC++ are turned off with a compiler switch (/EH- or omitting /EH, if I'm not mistaken), not a #define.
On 11/1/2013 10:03 AM, Peter Dimov wrote:
Edward Diener wrote:
Or is it just more realistic to say that compiling Boost libraries with RTTI disabled is not going to work ?
Some libraries, such as SmartPtr and, I believe, Function, are specifically made to work with RTTI disabled (and many do work with exceptions disabled). It's probably your #define that's causing the problem, not /GR-. Exceptions under VC++ are turned off with a compiler switch (/EH- or omitting /EH, if I'm not mistaken), not a #define.
Unforunately clang does not support MS's /EH in any way, even when emulating VC++. Also, in the build of clang with the VC++ iDE, the _HAS_EXCEPTIONS=0 define is being used extensively.
Edward Diener wrote:
Also, in the build of clang with the VC++ iDE, the _HAS_EXCEPTIONS=0 define is being used extensively.
Judging by the compiler error, it appears that the standard library doesn't define std::exception at all when _HAS_EXCEPTIONS=0. Boost libraries do depend on std::exception as a base class for their own exception types even when exceptions are off, so its absence is likely to break a lot of things, not just <typeinfo>.
On 11/1/2013 12:30 PM, Peter Dimov wrote:
Edward Diener wrote:
Also, in the build of clang with the VC++ iDE, the _HAS_EXCEPTIONS=0 define is being used extensively.
Judging by the compiler error, it appears that the standard library doesn't define std::exception at all when _HAS_EXCEPTIONS=0. Boost libraries do depend on std::exception as a base class for their own exception types even when exceptions are off, so its absence is likely to break a lot of things, not just <typeinfo>.
I agree with your analysis. In VC++ RTTI, aka typeinfo, cannot be used without std::exception support. But perhaps we can at least circumvent this in Boost.config by not including typeinfo for vc++ if RTTI is turned off, which seems reasonable. I will work with that scenario locally and see what happens next. If it is totally unrealistic trying to compile Boost libraries with clang on Windows if RTTI and exception handling are turned off, I will mention this on the clang developer's forum and post a bug report against it on clang bugzilla.
On Fri, Nov 1, 2013 at 1:54 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
On 11/1/2013 12:30 PM, Peter Dimov wrote:
Edward Diener wrote:
Also, in the build of clang with the VC++ iDE, the _HAS_EXCEPTIONS=0 define is being used extensively.
Judging by the compiler error, it appears that the standard library doesn't define std::exception at all when _HAS_EXCEPTIONS=0. Boost libraries do depend on std::exception as a base class for their own exception types even when exceptions are off, so its absence is likely to break a lot of things, not just <typeinfo>.
I agree with your analysis.
In VC++ RTTI, aka typeinfo, cannot be used without std::exception support. But perhaps we can at least circumvent this in Boost.config by not including typeinfo for vc++ if RTTI is turned off, which seems reasonable. I will work with that scenario locally and see what happens next. If it is totally unrealistic trying to compile Boost libraries with clang on Windows if RTTI and exception handling are turned off, I will mention this on the clang developer's forum and post a bug report against it on clang bugzilla.
IMO that is the best way to handle this. No point in Boosters putting in effort to work around a problem so serious it blocks most use of clang on windows anyhow. They will have to fix it if they are serious about clang and windows. If you send me the bugzilla number, I'll drop Chandler Carruth a note asking them to give it high priority. The squeaky wheel gets the grease. --Beman
On 1 Nov 2013 at 14:13, Beman Dawes wrote:
IMO that is the best way to handle this. No point in Boosters putting in effort to work around a problem so serious it blocks most use of clang on windows anyhow. They will have to fix it if they are serious about clang and windows.
Last time I looked clang could generate reasonably functional Win32 EH tables on 32 bit x86. x64 uses a different format, and wasn't working last time I looked. Just because clang can spit out the tables doesn't of course mean that clang's runtime can cope fully yet. Certain support library code would be needed, and I have no idea what the state of that is. I absolutely agree there is no point even thinking about Boost support for clang on Windows as if it were MSVC until they have MSVC native exception handling perfected and Win32 SEH as well, as that comes with the territory of full MSVC compliance. I'd also not bother until clang can fully grok all Win32 Platform SDK headers too, as Boost code will assume that works ifdef _MSC_VER and rightly so. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 11/1/2013 2:32 PM, Niall Douglas wrote:
On 1 Nov 2013 at 14:13, Beman Dawes wrote:
IMO that is the best way to handle this. No point in Boosters putting in effort to work around a problem so serious it blocks most use of clang on windows anyhow. They will have to fix it if they are serious about clang and windows.
Last time I looked clang could generate reasonably functional Win32 EH tables on 32 bit x86. x64 uses a different format, and wasn't working last time I looked.
Just because clang can spit out the tables doesn't of course mean that clang's runtime can cope fully yet. Certain support library code would be needed, and I have no idea what the state of that is.
I absolutely agree there is no point even thinking about Boost support for clang on Windows as if it were MSVC until they have MSVC native exception handling perfected and Win32 SEH as well, as that comes with the territory of full MSVC compliance. I'd also not bother until clang can fully grok all Win32 Platform SDK headers too, as Boost code will assume that works ifdef _MSC_VER and rightly so.
With exception support and RTTI current clang with VC++ RTL gives: "add_const_test.cpp" -Fo"..\..\..\bin.v2\libs\type_traits\test\add_const_test.test\clang-vc10-win-3.4\debug\add_const_test.obj" -TP /Od /Ob0 /W4 /GR /MDd /Zc:forScope /Zc:wchar_t -fmsc-version=1600 /wd4675 /EHs -c -DBOOST_ALL_NO_LIB=1 "-I..\..\.." compile-c-c++ ..\..\..\bin.v2\libs\type_traits\test\add_const_test.test\clang-vc10-win-3.4\debug\add_const_test.obj call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 > nul "C:\Programming\VersionControl\clang_build\bin\Release\clang-cl.exe" @"..\..\..\bin.v2\libs\type_traits\test\add_const_test.test\clang-vc10-win-3.4\debug\add_const_test.obj.rsp" clang-cl.exe: warning: argument unused during compilation: '/EHs' error: cannot mangle RTTI descriptors for type 'codecvt' yet error: cannot mangle the name of type 'codecvt' into RTTI descriptors yet error: cannot mangle RTTI descriptors for type 'codecvt_base' yet error: cannot mangle the name of type 'codecvt_base' into RTTI descriptors yet error: cannot mangle RTTI descriptors for type 'facet' yet error: cannot mangle the name of type 'facet' into RTTI descriptors yet 6 errors generated.""
On 11/1/2013 2:13 PM, Beman Dawes wrote:
On Fri, Nov 1, 2013 at 1:54 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
On 11/1/2013 12:30 PM, Peter Dimov wrote:
Edward Diener wrote:
Also, in the build of clang with the VC++ iDE, the _HAS_EXCEPTIONS=0 define is being used extensively.
Judging by the compiler error, it appears that the standard library doesn't define std::exception at all when _HAS_EXCEPTIONS=0. Boost libraries do depend on std::exception as a base class for their own exception types even when exceptions are off, so its absence is likely to break a lot of things, not just <typeinfo>.
I agree with your analysis.
In VC++ RTTI, aka typeinfo, cannot be used without std::exception support. But perhaps we can at least circumvent this in Boost.config by not including typeinfo for vc++ if RTTI is turned off, which seems reasonable. I will work with that scenario locally and see what happens next. If it is totally unrealistic trying to compile Boost libraries with clang on Windows if RTTI and exception handling are turned off, I will mention this on the clang developer's forum and post a bug report against it on clang bugzilla.
IMO that is the best way to handle this. No point in Boosters putting in effort to work around a problem so serious it blocks most use of clang on windows anyhow. They will have to fix it if they are serious about clang and windows.
If you send me the bugzilla number, I'll drop Chandler Carruth a note asking them to give it high priority. The squeaky wheel gets the grease.
I filed the bug report and it is #17773 at http://llvm.org/bugs/show_bug.cgi?id=17773.
On 1 Nov 2013 at 9:38, Edward Diener wrote:
enabled ? Or is it just more realistic to say that compiling Boost libraries with RTTI disabled is not going to work ?
FYI on Nov 11th Boost.TypeIndex will come up for peer review. If accepted, a large chunk of Boost's dependency on RTTI can be eliminated, and there are patches ready to go replacing std::type_info with boost::type_info across many Boost libraries. Most of Boost would then work with RTTI off. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
participants (4)
-
Beman Dawes -
Edward Diener -
Niall Douglas -
Peter Dimov