Re: [threads] contention for MSCRT's_pRawDllMain hook in static library

"Evan Burkitt" <eburkitt <at> gmail.com> writes:

> I'm using VS2005 to compile a DLL that links with the MFC DLL and also the
> static Boost threads library. I've upgraded from Boost v1.34.1 to v1.37 and
> now the threads library's use of MSCRT's _pRawDllMain hook interferes with
> MFC's use of the hook to point to its _RawDllMain export. I've come up with
> a workaround of a library that exports _pRawDllMain and links to _RawDllMain
> in the MFC DLL and an export I've added to the threads library that calls
> its dll_callback() function. I just can't get the MS linker to cooperate.

I figured this would conflict with something. I didn't realise it
would be MFC 

I use this hook to allow a DLL that is statically linked with
Boost.Thread to correctly clean up thread local data, since Windows
doesn't call the TLS callbacks for DLLs but it *does* call the DLL
entry point.

> If I put my library ahead of the threads library in the command line the
> linker complains of a multiply-defined symbol. If I put the threads library
> ahead of my library the linker uses the threads library _pRawDllMain export
> and ignores mine. Only if I remove the _pRawDllMain export from the threads
> library entirely does the linker use mine. I would like to leave the
> _pRawDllMain export in the threads library so that it will still work in my
> library's absence but I can't figure out what makes it so attractive to the
> linker.

The _pRawDllMain export in Boost.Thread is in the same .obj file as
other code that is needed.

If you move it out from tss_pe.cpp to its own .cpp file it might work.

Anthony
--

-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams

Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK