"Anthony Williams" <anthony.ajw@gmail.com> wrote in message news:u1vx8lhj0.fsf@gmail.com...
"Evan Burkitt" <eburkitt@gmail.com> 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