From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11671 invoked by alias); 29 May 2007 12:36:44 -0000 Received: (qmail 11663 invoked by uid 22791); 29 May 2007 12:36:43 -0000 X-Spam-Check-By: sourceware.org Received: from quokka.dot.net.au (HELO quokka.dot.net.au) (202.147.68.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 May 2007 12:36:39 +0000 Received: from [203.129.44.110] (helo=[203.129.44.110]) by quokka.dot.net.au with esmtp (Exim 3.35 #1 (Debian)) id 1Ht0w7-0003E5-00; Tue, 29 May 2007 22:36:27 +1000 Message-ID: <465C1E4D.4000906@homemail.com.au> Date: Thu, 31 May 2007 07:23:00 -0000 From: Ross Johnson User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Marc Peter CC: pthreads-win32@sourceware.org Subject: Re: OpenWatcom 1.6 passes tests with DLL build References: <465B34FA.2010902@gmx.de> In-Reply-To: <465B34FA.2010902@gmx.de> 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: 2007/txt/msg00031.txt.bz2 Hi Marc, This is good news. Sending a small patch via the list is fine I think and if in doubt you can send direct to me. I'll endeavour to get it into the next release, which is long overdue. Could you please include your Wmakefile - I'm sure I had one at some point but I can't find it here anywhere. Regards. Ross Marc Peter wrote: > Hi, > > I've managed to build a DLL version of the library with Open Watcom 1.6 > which passes all tests after only slight modifications to the source. > > I used the CVS sources. > > Here is a short summary of the changes I made: > - use the -br compiler switch for both the library and the tests > This is necessary so both, library and application, use the same > run-time library instance. This fixes the errno problem mentioned > in README.Watcom.[1] > - enable inclusion of > Open Watcom has int64_t in this header. > - define PTW32_CDECL to be empty > This prevents compilation errors in tests, where calling conventions > for callbacks don't match. This could also have been fixed by using > proxy functions for the callbacks in the tests, but I went for the > quick fix.[2] > - use #pragma aux syntax for inline assembly > This is more efficient then _asm { ... } syntax and doesn't require > to disable any compiler warnings. > - fix Wamekefile in the "tests" directory > Some extensions in the PASSES variable were missing. > > The patch is 225 lines long, my experimental make file has another 22 > lines. If it is okay with the policy of this list, I can attach them in > another message. > > Note: > The "Wmakefile" mentioned in README.Watcom was nowhere to be found. > > I have not performed any regression tests with other compilers, but I > don't expect any incompatibilities. > > > best regards > Marc > > > [1] As soon as a thread is started, the CRT must behave slightly > different, for instance lock concurrently used resources such as > the heap during malloc/free calls. This is the reason why new > threads must be created with a CRT function like _beginthread(ex), > and not by calling the Win32 API directly. > > [2] __cdecl was only chosen so a DLL created with Open Watcom can be > used with different compilers. But mixing runtime libraries of > different compilers is another step further towards "interesting" > behavior than using two instances of the same CRT - see errno > problem. So, if we restrict the DLL to be only used with Watcom > generated applications, we can safely use register based calling. > > >