public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Ross Johnson <Ross.Johnson@homemail.com.au>
To: Brian Cole <coleb2@gmail.com>
Cc: pthreads-win32@sourceware.org
Subject: Re: Static Library Initialization (again?)
Date: Wed, 18 Jun 2008 01:25:00 -0000	[thread overview]
Message-ID: <485863D6.3000203@homemail.com.au> (raw)
In-Reply-To: <54b165660806171627i489ec78at85e8576762fe97af@mail.gmail.com>

Brian Cole wrote:
> 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?
>   
A patch based on the Boost solution would be very welcome. It looks to 
me like both Google and Boost are using the same technique but the Boost 
version appears to include a version for Mingw32.

I'm not familiar with this enough to tell - does this solution work for 
dynamic loading as well, or just static? I ask because there are a 
couple of calls in DllMain that are forbidden according to the Microsoft 
doco, such as calling LoadLibrary, but work anyway.

> -Brian
>   

  reply	other threads:[~2008-06-18  1:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-17 23:28 Brian Cole
2008-06-18  1:25 ` Ross Johnson [this message]
2008-06-18 14:09 ` John E. Bossom
2009-05-22  0:08 ` Ramiro Polla
2009-05-22  2:36   ` John E. Bossom
2009-06-07 23:39   ` Ramiro Polla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=485863D6.3000203@homemail.com.au \
    --to=ross.johnson@homemail.com.au \
    --cc=coleb2@gmail.com \
    --cc=pthreads-win32@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).