public inbox for
 help / color / mirror / Atom feed
From: Ross Johnson <>
To: Martin Lambers <>
Subject: Re: Pthreads-win32 and static linking
Date: Sun, 20 Jun 2010 05:15:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20100510195037.GA7348@lambers.home>

Martin Lambers wrote:
> Hello!
> The Mingw-cross-env project provides a MinGW cross-compiling environment
> for POSIX systems. For various reasons, all included libraries are
> static, including the pthreads-win32 library.
> This means that all pthreads users need to call
> pthread_win32_thread_attach_np() and pthread_win32_thread_detach_np() in
> each thread function.
Only Windows native threads that call POSIX threads routines. See note 
> We would like to avoid patching all libraries that use pthread, and
> instead change pthreads-win32: instead of using a thread main function
> given to pthread_create() directly, pthreads-win32 could use an internal
> wrapper that calls the thread main function and also calls the
> attach/detach functions if necessary.
Hi Martin,

Apologies for the slow response.

Please try the current pthreads-win32 CVS repository head version. 
Anonymous CVS access instructions are on our web page at
I've applied most of Ramiro Polla's patches and tested the MinGW32 GCC 
static build across the full test suite. The patches that I've omitted 
are just conditional compiler directives that broke the DLL build and 
did not appear to affect the static build. I've emailed Ramiro privately 
for comment.

Everyone may like to note:
It is not necessary to call pthread_win32_thread_*_np() for any threads 
created through pthread_create(). That is only necessary for Windows 
native threads that call POSIX API routines in order to interact with 
POSIX threads and only when statically linked (often only the primary 
Windows thread). That is, pthread_create() already effectively does what 
Martin has suggested. I've updated the README.NONPORTABLE file to 
hopefully make that clearer.

So with Ramiro's patches most applications should now run unmodified 
when statically linked.

This otherwise transparent ability for Windows and POSIX threads to 
freely interact (via either API) is an aspect of John Bossom's original 
code that has been deliberately retained throughout the evolution of the 


  parent reply	other threads:[~2010-06-20  5:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-10 19:50 Martin Lambers
2010-05-10 20:03 ` Ramiro Polla
2010-06-20  5:15 ` Ross Johnson [this message]
2010-07-23 12:09   ` John E. Bossom

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:

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

  git send-email \ \ \ \ \

* 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).