From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4377 invoked by alias); 31 Mar 2005 08:29:58 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 4175 invoked from network); 31 Mar 2005 08:29:49 -0000 Received: from unknown (HELO quokka.dot.net.au) (202.147.68.16) by sourceware.org with SMTP; 31 Mar 2005 08:29:49 -0000 Received: from [202.147.81.148] (helo=ip-81-148.dot.net.au) by quokka.dot.net.au with esmtp (Exim 3.35 #1 (Debian)) id 1DGv3j-0003lK-00 for ; Thu, 31 Mar 2005 18:29:47 +1000 Subject: Re: Re: Static link (MSVC), alteration proposal From: Ross Johnson To: Pthreads-Win32 list In-Reply-To: <1112254930.d6fc30c99fd62@mail.bg> References: <1112192108.9a7b65f2515a2@mail.bg> <1112226518.19990.69.camel@desk.home> <1112254930.d6fc30c99fd62@mail.bg> Content-Type: text/plain Date: Thu, 31 Mar 2005 08:29:00 -0000 Message-Id: <1112257786.19990.180.camel@desk.home> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005/txt/msg00053.txt.bz2 On Thu, 2005-03-31 at 10:42 +0300, Dimitar Panayotov wrote: > > Hi, > > Thanks for the changes and the explanations. They > > certainly fill a gap. > > Hello, Ross, and thank you for your detailed attention you > attested. > > > The PTW32_BUILD conditional was added by me. I've never > > built the > > library statically, and don't test this side of things. > > This is because > > the library is essentially designed for dynamic linking > > No, PTW32 is written very clever. > Much has been added or modified since John Bossom contributed his original version of the library, but a fundamental design feature from that version that has been kept is the ability of Win32 threads to call POSIX routines, and thus become pseudo POSIX threads. This requires some behind-the-scene work to manage, and it's important that cleaning up be done when these threads exit, or the process exits. For this to be seamless and transparent to an application that uses the library ideally requires the dllMain feature. > 1. Since the sources are written in a way which relies on > the headers to determine the type of linkage of all the > PTW32 functions, then actually everything is up to the > headers. > 2. Since all the sources are combined in single one -- > , things are quite easy, because you only need > to add to your project (or give to it a > separate entry in the Makefile), it will be compiled, and > then pthread.obj will be included in the final link, and > that's it. > Yes, you can do that. This was how John's original version was presented. Then I split the routines out into separate modules so that a static library could be built such that any static linking exe could include only those routines it needed (for embedded applications). But apparently all of the target compilers include options to do this automatically anyway. The monolithic pthread.c file is intended primarily to reassemble all of the modules into a single compilation unit in an attempt to maximise inlining of functions within the library. > I admit that the style of the people who have written PTW32, > is professional. All of the contributions to the library have been absolutely awesome. Regards. Ross