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

"Anthony Williams" wrote in message news:u1vx8lhj0.fsf@gmail.com...

"Evan Burkitt" writes:

...

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.

Ah! That makes sense.

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

It didn't. I put the _pRawDllMain export and the dll_callback() function it points to in their own file, but the linker still complained. What does work is link's /force:multiple command line switch. This makes my library order fiddling work, so I can live with it for now. Obviously it would be nice to figure out a way to automate the linking. Off the top of my head, creating a separate static library for DLLs that use the MFC DLL is one solution, with code in dll_callback() inside a #ifdef _AFXDLL conditional to pass control to an extern "C" _RawDllMain. Maybe something cleverer will come to mind after a night's sleep. Thanks for your help. -evan