Thread-specific pointers versus MFC (Microsoft)
I see a thread about this issue from 2009, with no resolution. A possible patch was mentioned but there was never a followup. We picked up the thread-specific pointer goodness with 1.35, under Visual Studio 2008. We stayed with that combination ever since, for stability. Now I'm looking at VS2010 and 1.44. To support Microsoft's thread model in DLL (dynamically linked libraries) in 1.35 required the user to intercept library unload events. Shortly after 1.35, the boost thread library was enhanced to take care of this for you. The hook it uses, however, conflicts with the use of that same hook by Microsoft's MFC library, when you are building an "MFC Extension DLL" specifically. We have a bunch of that going on. The conflict ends up being detected at link time, like this: 1>libboost_thread-vc100-mt-gd-1_44.lib(tss_pe.obj) : error LNK2005: _pRawDllMain already defined in Table.obj The archive discussion http://thread.gmane.org/gmane.comp.lib.boost.user/46509/focus=46706 What is the current thinking on this issue? I don't see any #ifdef logic in the boost headers that looks like it might be intended to address this, do I need to hack it myself or is there an established work-around? And don't dog me about MFC. Some of the code I'm dealing with is still in FORTRAN, and some is 25-year-old C. Thanks! -swn
participants (1)
-
Stephen Nuchia