Ben | 22 Jun 10:05 2009
Picon

link problem: _pRawDllMain conflict issue

I encounter the link problem that is described in another mail: http://lists.boost.org/Archives/boost/2009/02/148419.php

As mentioned in the URL, the _pRawDllMain instance conflicts with another instance defined in MFC since boost 1.37.0. DLL version of Boost.thread is recommended.

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. The pri-compiled binary files downloaded from Boost Pro don't have digital sign, either.

Ok, the DLL version can't meet our requirement. Will the _pRawDllMain conflict issue be resolved in the next version?
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.
Thanks.

<div><p>I encounter the link problem that is described in another mail: <a href="http://lists.boost.org/Archives/boost/2009/02/148419.php" target="_blank">http://lists.boost.org/Archives/boost/2009/02/148419.php</a><br><br>As
mentioned in the URL, the _pRawDllMain instance conflicts with another
instance defined in MFC since boost 1.37.0. DLL version of Boost.thread
is recommended.<br><br>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. The pri-compiled binary files downloaded
from Boost Pro don't have digital sign, either.<br><br>Ok, the DLL version can't meet our requirement. Will the _pRawDllMain conflict issue be resolved in the next version?<br>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.<br>
Thanks.
</p></div>
Anthony Williams | 22 Jun 10:48 2009
Picon

Re: link problem: _pRawDllMain conflict issue

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, 
though.

> 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.

Anthony
--

-- 
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
Ben | 22 Jun 18:00 2009
Picon

Re: link problem: _pRawDllMain conflict issue



2009/6/22 Anthony Williams <anthony <at> justsoftwaresolutions.co.uk>
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?
Due to our legal policy, we don't sign the DLLs which are not our own software. I know that it's weird because we do sign to the DLLs that statically link with Boost libs. The DLLs, of course, contains Boost codes are still signed. But it's legal policy. What can I say?
BTW, in the point of view from our programmers, we like static Boost libraries more. Not to mention that there's (was?) a bug about auto linking if we want to use Boost DLLs.



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, though.
I didn't trace deep into the source codes. Is it really necessary to use thread-locals?



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.
Unfortunately, we are linking statically against boost.thread from a DLL which use MFC. And we don't want to modify any source code of Boost especially when we need to sync the changes between hundreds of programers.
I don't think that calling TlsFree() in on_process_exit is a good idea because it should be called when the DLL unloads. If the DLL is loaded/unloaded dynamically by LoadLibrary()/FreeLibrary(), the timing when DLL unloads will be different from the timing when process exists.

Since the Boost library doesn't meet our requirement and we don't want to modify our codes that uses Boost.Thread, my quick solution is to implement these facilities that we had used in Boost.Thread. It's lucky that we only use some simple tools: thread creation/join, recursive_mutex(and it's scoped_lock), condition. So I implement them and it looks like we can avoid this leak/link issue.
 


Anthony
--
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
_______________________________________________
threads-devel mailing list
threads-devel <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/threads-devel

<div>
<br><br><div class="gmail_quote">2009/6/22 Anthony Williams <span dir="ltr">&lt;<a href="mailto:anthony <at> justsoftwaresolutions.co.uk">anthony <at> justsoftwaresolutions.co.uk</a>&gt;</span><br><blockquote class="gmail_quote">
<div class="im">Ben wrote:<br><blockquote class="gmail_quote">
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. <br>
</blockquote>
<br>
</div>
I will take your word for this, but I don't understand: if you build them inhouse, why can't you sign them?</blockquote>
<div>Due to our legal policy, we don't sign the DLLs which are not our own software. I know that it's weird because we do sign to the DLLs that statically link with Boost libs. The DLLs, of course, contains Boost codes are still signed. But it's legal policy. What can I say?<br>
BTW, in the point of view from our programmers, we like static Boost libraries more. Not to mention that there's (was?) a bug about auto linking if we want to use Boost DLLs.<br><br>
</div>
<blockquote class="gmail_quote">
<div class="im">
<br><br><blockquote class="gmail_quote">
Ok, the DLL version can't meet our requirement. Will the _pRawDllMain conflict issue be resolved in the next version?<br>
</blockquote>
<br>
</div>
It won't be in 1.40.0. I will endeavour to get the fix in sometime soon, though.</blockquote>
<div>I didn't trace deep into the source codes. Is it really necessary to use thread-locals? <br><br>
</div>
<blockquote class="gmail_quote">
<div class="im">
<br><br><blockquote class="gmail_quote">
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.<br>
</blockquote>
<br>
</div>
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.<br><br>
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.<br><br>
If you are linking boost.thread directly into the EXE then you can remove this use of _pRawDllMain anyway with no averse consequences.</blockquote>
<div>Unfortunately, we are linking statically against boost.thread from a DLL which use MFC. And we don't want to modify any source code of Boost especially when we need to sync the changes between hundreds of programers.<br>
I don't think that calling TlsFree() in on_process_exit is a good idea because it should be called when the DLL unloads. If the DLL is loaded/unloaded dynamically by LoadLibrary()/FreeLibrary(), the timing when DLL unloads will be different from the timing when process exists.<br><br>Since the Boost library doesn't meet our requirement and we don't want to modify our codes that uses Boost.Thread, my quick solution is to implement these facilities that we had used in Boost.Thread. It's lucky that we only use some simple tools: thread creation/join, recursive_mutex(and it's scoped_lock), condition. So I implement them and it looks like we can avoid this leak/link issue.<br>
&nbsp;<br>
</div>
<blockquote class="gmail_quote">
<br><br>
Anthony<br>
-- <br>
Author of C++ Concurrency in Action | <a href="http://www.manning.com/williams" target="_blank">http://www.manning.com/williams</a><br>
just::thread C++0x thread library &nbsp; | <a href="http://www.stdthread.co.uk" target="_blank">http://www.stdthread.co.uk</a><br>
Just Software Solutions Ltd &nbsp; &nbsp; &nbsp; &nbsp; | <a href="http://www.justsoftwaresolutions.co.uk" target="_blank">http://www.justsoftwaresolutions.co.uk</a><br>
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976<br>
_______________________________________________<br>
threads-devel mailing list<br><a href="mailto:threads-devel <at> lists.boost.org" target="_blank">threads-devel <at> lists.boost.org</a><br><a href="http://lists.boost.org/mailman/listinfo.cgi/threads-devel" target="_blank">http://lists.boost.org/mailman/listinfo.cgi/threads-devel</a><br>
</blockquote>
</div>
<br>
</div>

Gmane