* OpenWatcom 1.6 passes tests with DLL build
@ 2007-05-29 12:36 Marc Peter
2007-05-31 7:23 ` Ross Johnson
0 siblings, 1 reply; 2+ messages in thread
From: Marc Peter @ 2007-05-29 12:36 UTC (permalink / raw)
To: pthreads-win32
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: OpenWatcom 1.6 passes tests with DLL build
2007-05-29 12:36 OpenWatcom 1.6 passes tests with DLL build Marc Peter
@ 2007-05-31 7:23 ` Ross Johnson
0 siblings, 0 replies; 2+ messages in thread
From: Ross Johnson @ 2007-05-31 7:23 UTC (permalink / raw)
To: Marc Peter; +Cc: pthreads-win32
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 <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.
>
>
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-05-29 12:36 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-05-29 12:36 OpenWatcom 1.6 passes tests with DLL build Marc Peter
2007-05-31 7:23 ` Ross Johnson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).