"Evan Burkitt" 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