Boost logo

Threads-Devel :

Subject: Re: [Threads-devel] link problem: _pRawDllMain conflict issue
From: Anthony Williams (anthony_at_[hidden])
Date: 2009-06-22 04:48:54

Ben wrote:
> 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 |
just::thread C++0x thread library   |
Just Software Solutions Ltd         |
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at