Re: Pthreads-win32 and static linking

["John E. Bossom" <drifting at pioneerwireless dot ca>]

Thanks, Ross...

The original intent when I first wrote the original library was to
have the pthreads-win32 library be usable for those that also wrote
IIS plugin/dlls ... i.e. Windows creates the thread of execution prior
to calling your own plugin... I wanted to seamlessly plug-into the
already created thread.
(Yes... I'm still lurking around ;^)

John E. Bossom


Quoting Ross Johnson <Ross.Johnson@homemail.com.au>:

> 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 below.
> > 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
> http://sourceware.org/pthreads-win32
> 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 library.
>
> Regards.
> Ross