From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30362 invoked by alias); 20 Jun 2010 05:15:58 -0000 Received: (qmail 30354 invoked by uid 22791); 20 Jun 2010 05:15:57 -0000 X-SWARE-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40 X-Spam-Check-By: sourceware.org Received: from flexo.grapevine.net.au (HELO flexo.grapevine.net.au) (203.129.32.140) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 20 Jun 2010 05:15:52 +0000 Received: from localhost (localhost [127.0.0.1]) by flexo.grapevine.net.au (Postfix) with ESMTP id 5C8175E8145; Sun, 20 Jun 2010 15:15:48 +1000 (EST) Received: from flexo.grapevine.net.au ([127.0.0.1]) by localhost (flexo.grapevine.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x7FsLjZLAkK; Sun, 20 Jun 2010 15:15:48 +1000 (EST) Received: from [10.1.1.16] (unknown [180.200.141.130]) (Authenticated sender: Ross.Johnson@homemail.com.au) by flexo.grapevine.net.au (Postfix) with ESMTP id 0554B5E8144; Sun, 20 Jun 2010 15:15:47 +1000 (EST) Message-ID: <4C1DA3D3.5050102@homemail.com.au> Date: Sun, 20 Jun 2010 05:15:00 -0000 From: Ross Johnson User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Martin Lambers CC: pthreads-win32@sourceware.org Subject: Re: Pthreads-win32 and static linking References: <20100510195037.GA7348@lambers.home> In-Reply-To: <20100510195037.GA7348@lambers.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2010/txt/msg00010.txt.bz2 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