This is the mail archive of the pthreads-win32@sourceware.org mailing list for the pthreas-win32 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]