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

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 
news:u1vx8lhj0.fsf_at_gmail.com...
> "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 
>> 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