This is the mail archive of the
pthreads-win32@sourceware.org
mailing list for the pthreas-win32 project.
OpenWatcom 1.6 passes tests with DLL build
- From: Marc Peter <macpete at gmx dot de>
- To: pthreads-win32 at sourceware dot org
- Date: Mon, 28 May 2007 22:00:58 +0200
- Subject: OpenWatcom 1.6 passes tests with DLL build
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 <stdint.h>
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.