Boost Users :
Subject: Re: [Boost-users] [threads] contention for MSCRT's_pRawDllMain hook in static library
From: Evan Burkitt (eburkitt_at_[hidden])
Date: 2008-11-18 23:36:11
"Anthony Williams" <anthony.ajw_at_[hidden]> wrote in message
> "Evan Burkitt" <eburkitt_at_[hidden]> 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
>> ahead of my library the linker uses the threads library _pRawDllMain
>> and ignores mine. Only if I remove the _pRawDllMain export from the
>> 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
>> library's absence but I can't figure out what makes it so attractive to
> 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.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net