Subject: Re: [Threads-devel] link problem: _pRawDllMain conflict issue
From: Anthony Williams (anthony_at_[hidden])
Date: 2009-06-22 04:48:54
> I can't, however, use this version because all exe/DLL files shipped
> from our company need a digital sign to pass Vista/Win7 logo. Since
> boost is released in the form of source codes, the DLL files will be
> built by ourselves. But we can't sign the Boost DLL files since they are
> not made by our company.
I will take your word for this, but I don't understand: if you build
them inhouse, why can't you sign them?
> Ok, the DLL version can't meet our requirement. Will the _pRawDllMain
> conflict issue be resolved in the next version?
It won't be in 1.40.0. I will endeavour to get the fix in sometime soon,
> By the way, we are now using Boost 1.35.0 and found that the TLSFree()
> is not called and caused a resource link that make us failed to pass the
> Vista/Win7 logo test. So we tried Boost 1.39.0 and encountered the link
> conflict issue.
How are you using boost.thread? This should only be a problem if you are
linking statically against boost.thread from a DLL. If you do this, you
need to be aware that thread-locals are thus isolated to that DLL, and
are not accessible from other DLLs, even on the same thread.
TlsFree is only called on process shut-down. If you can ensure that
on_process_exit from boost/thread/detail/tss_hooks.hpp is called when
the DLL is unloaded then you can patch libs/thread/src/win32/tss_pe.cpp
to remove the use of _pRawDllMain.
If you are linking boost.thread directly into the EXE then you can
remove this use of _pRawDllMain anyway with no averse consequences.
-- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976