This is the mail archive of the
pthreads-win32@sourceware.org
mailing list for the pthreas-win32 project.
Static Library Initialization (again?)
- From: "Brian Cole" <coleb2 at gmail dot com>
- To: pthreads-win32 at sourceware dot org
- Date: Tue, 17 Jun 2008 17:27:32 -0600
- Subject: Static Library Initialization (again?)
It looks like I'm running into the same problem as others. I need to
distribute a static library with pthreads-win32 included without
requiring end-users of our library to call any pthreads-win32 specific
attach or detach code. Based on previous posts to the mailing list it
looks like the boost library has dealt with this before:
http://sourceware.org/ml/pthreads-win32/2008/msg00022.html
I also found this bit of code inside the Google performance tools:
#ifdef _MSC_VER
// This tells the linker to run these functions.
#pragma data_seg(push, old_seg)
#pragma data_seg(".CRT$XLB")
static void (NTAPI *p_thread_callback)(HINSTANCE h, DWORD dwReason, PVOID pv)
= on_tls_callback;
#pragma data_seg(".CRT$XTU")
static int (*p_process_term)(void) = on_process_term;
#pragma data_seg(pop, old_seg)
#else // #ifdef _MSC_VER [probably msys/mingw]
// We have to try the DllMain solution here, because we can't use the
// msvc-specific pragmas.
<snipped for brevity>
#endif // #ifdef _MSC_VER
Any reason pthreads-win32 can't use these same mechanisms to initialize itself?
Why can't DllMain be used for this? MSDN seems to imply that DllMain
is called for static libraries
(http://msdn.microsoft.com/en-us/library/ms682583.aspx):
"The lpReserved parameter indicates whether the DLL is being loaded
statically or dynamically."
I just looked through boost and found their implementation
(boost-trunk/libs/thread/src/win32/tss_pe.cpp). Any objection to me
creating a patch based on this code for pthreads-win32?
-Brian