[Boost-users] Thread-specific pointers versus MFC (Microsoft)

Subject: [Boost-users] Thread-specific pointers versus MFC (Microsoft)
From: Stephen Nuchia (snuchia_at_[hidden])
Date: 2011-01-20 18:11:38

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