boost::thread problems with Visual Studio SP1 & /clr

A while ago I posted a problem to the list about issues I was having using the beta Visual Studio SP1, statically linking to boost::threads and compiling with /clr ( http://thread.gmane.org/gmane.comp.lib.boost.user/22464/focus=22617 ). SP1 has been recently released and the problem still exists. I resubmitted a bug report to Microsoft and they have marked the bug as [Won't Fix]. https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba... A workaround is to use the DLL version of boost::threads. This is not ideal, as I'd rather not have yet another DLL to cart around with my application. I'm guessing that supporting the /clr switch in boost isn't a high priority but it is the most straightforward way to integrate portable code ( communications, etc ) into a C# application. John

John Dunn wrote:
A workaround is to use the DLL version of boost::threads. This is not ideal, as I'd rather not have yet another DLL to cart around with my application. I'm guessing that supporting the /clr switch in boost isn't a high priority but it is the most straightforward way to integrate portable code ( communications, etc ) into a C# application.
I did not yet have time to look into this. It is on my todo list... Roland

Roland Schwarz wrote:
I did not yet have time to look into this. It is on my todo list...
Roland
The following comment was posted on my bug report in MS Connect - ----- The triage team had the following brief comment about the issue: This looks as if the issue is by design. Some of the termination code change in SP1 to fix defects. If Boost is using undocumented APIs, it is a problem that needs to be fixed there. Aside from that, architectural changes to loader lock will not be undertaken now in the Orcas release, so this issue would not meet the Orcas triage guidelines. ----- So it doesn't look like it will be addressed on the MS end. At a minimum it would be nice if compilation would fail ( with a somewhat friendly error message ) when a user tried to statically link with boost::threads with the /clr flag. That would probably save a few people the same headache I went through trying to determine why my program was crashing. John
participants (2)
-
John Dunn
-
Roland Schwarz