Re: [Boost-users] VS2010 and /clr: fatal error C1001: An internal error has occurred in the compiler
Probably because that causes some assembly to be emitted because of the efficiency requirements of the mutex, and the CLR does not support direct assembly. Either get out of the CLR, or do not use anything that uses low assembly constructs (CLR has its own thread and mutex classes anyway).
Well, so I can't "just get out of the CLR". As I mentioned earlier, this is a managed C++ project that exposes native functionality from other libraries to .NET. That is, I *have* to include the native headers, which in turn include boost. This worked fine in VS2008, too, so it sounds more like a regression in the compiler I think. Also, when compiling for x86, I see the following warning but everything still compiles (the warning is to be expected, as you say yourself): 4>boost_1_43_0_sdk\include\boost\thread\win32\basic_timed_mutex.hpp(160) : warning C4793: 'boost::detail::basic_timed_mutex::unlock' : function compiled as native : 4> Found an intrinsic not supported in managed code / Soren
On Sun, Aug 8, 2010 at 9:43 AM, Soren Dreijer
Probably because that causes some assembly to be emitted because of the efficiency requirements of the mutex, and the CLR does not support direct assembly. Either get out of the CLR, or do not use anything that uses low assembly constructs (CLR has its own thread and mutex classes anyway).
Well, so I can't "just get out of the CLR". As I mentioned earlier, this is a managed C++ project that exposes native functionality from other libraries to .NET. That is, I *have* to include the native headers, which in turn include boost.
This worked fine in VS2008, too, so it sounds more like a regression in the compiler I think.
Also, when compiling for x86, I see the following warning but everything still compiles (the warning is to be expected, as you say yourself):
4>boost_1_43_0_sdk\include\boost\thread\win32\basic_timed_mutex.hpp(160): warning C4793: 'boost::detail::basic_timed_mutex::unlock' : function compiled as native : 4> Found an intrinsic not supported in managed code
Best bet might be to just compile it as a native dll, and P/Invoke what you need in. You lose multi-platformdness if you care about going to Mono, but you are using the CLR anyway so you probably do not care about multi-platform...
participants (2)
-
OvermindDL1 -
Soren Dreijer