Changes to documentation and makefiles.

1 files changed, 451 insertions, 419 deletions

diff --git a/README b/README
index b4e0288..1e49e74 100644
--- a/README
+++ b/README
@@ -1,419 +1,451 @@
-PTHREADS-WIN32
-==============
-
-Pthreads-win32 is free software, distributed under the GNU Lesser
-General Public License (LGPL). See the file 'COPYING.LIB' for terms
-and conditions. Also see the file 'COPYING' for information
-specific to pthreads-win32, copyrights and the LGPL.
-
-
-What is it?
------------
-
-Pthreads-win32 is an Open Source Software implementation of the
-Threads component of the POSIX 1003.1c 1995 Standard for Microsoft's
-Win32 environment. Some functions from POSIX 1003.1b are also
-supported including semaphores. Other related functions include
-the set of read-write lock functions. The library also supports
-some of the functionality of the Open Group's Single Unix
-specification, version 2, namely mutex types.
-
-See the file "ANNOUNCE" for more information including standards
-conformance details and list of supported routines.
-
-
-Which of the several dll versions to use?
------------------------------------------
-or,
----
-What are all these pthread*.dll and pthread*.lib files?
--------------------------------------------------------
-
-Simply, you only use one of them, but you need to choose carefully.
-
-The most important choice you need to make is whether to use a
-version that uses exceptions internally, or not (there are versions
-of the library that use exceptions as part of the thread
-cancelation and exit implementation, and one that uses
-setjmp/longjmp instead).
-
-There is some contension amongst POSIX threads experts as
-to how POSIX threads cancelation and exit should work
-with languages that include exceptions and handlers, e.g.
-C++ and even C (Microsoft's Structured Exceptions).
-
-The issue is: should cancelation of a thread in, say,
-a C++ application cause object destructors and C++ exception
-handlers to be invoked as the stack unwinds during thread
-exit, or not?
-
-There seems to be more opinion in favour of using the
-standard C version of the library (no EH) with C++ applications
-since this appears to be the assumption commercial pthreads
-implementations make. Therefore, if you use an EH version
-of pthreads-win32 then you may be under the illusion that
-your application will be portable, when in fact it is likely to
-behave very differently linked with other pthreads libraries.
-
-Now you may be asking: why have you kept the EH versions of
-the library?
-
-There are a couple of reasons:
-- there is division amongst the experts and so the code may
-  be needed in the future. (Yes, it's in the repository and we
-  can get it out anytime in the future, but ...)
-- pthreads-win32 is one of the few implementations, and possibly
-  the only freely available one, that has EH versions. It may be
-  useful to people who want to play with or study application
-  behaviour under these conditions.
-
-
-Library naming
---------------
-
-Because the library is being built using various exception
-handling schemes and compilers - and because the library
-may not work reliably if these are mixed in an application,
-each different version of the library has it's own name.
-
-Note 1: the incompatibility is really between EH implementations
-of the different compilers. It should be possible to use the
-standard C version from either compiler with C++ applications
-built with a different compiler. If you use an EH version of
-the library, then you must use the same compiler for the
-application. This is another complication and dependency that
-can be avoided by using only the standard C library version.
-
-Note 2: if you use a standard C pthread*.dll with a C++
-application, then any functions that you define that are
-intended to be called via pthread_cleanup_push() must be
-__cdecl.
-
-Note 3: the intention is to also name either the VC or GC
-version (it should be arbitrary) as pthread.dll, including
-pthread.lib and libpthread.a as appropriate.
-
-In general:
-	pthread[VG]{SE,CE,C}.dll
-	pthread[VG]{SE,CE,C}.lib
-
-where:
-	[VG] indicates the compiler
-	V	- MS VC
-	G	- GNU C
-
-	{SE,CE,C} indicates the exception handling scheme
-	SE	- Structured EH
-	CE	- C++ EH
-	C       - no exceptions - uses setjmp/longjmp
-
-For example:
-	pthreadVSE.dll	(MSVC/SEH)
-	pthreadGCE.dll	(GNUC/C++ EH)
-	pthreadGC.dll   (GNUC/not dependent on exceptions)
-
-The GNU library archive file names have changed to:
-
-	libpthreadGCE.a
-	libpthreadGC.a
-
-
-Other name changes
-------------------
-
-All snapshots prior to and including snapshot 2000-08-13
-used "_pthread_" as the prefix to library internal
-functions, and "_PTHREAD_" to many library internal
-macros. These have now been changed to "ptw32_" and "PTW32_"
-respectively so as to not conflict with the ANSI standard's
-reservation of identifiers beginning with "_" and "__" for
-use by compiler implementations only.
-
-If you have written any applications and you are linking
-statically with the pthreads-win32 library then you may have
-included a call to _pthread_processInitialize. You will
-now have to change that to ptw32_processInitialize.
-
-
-A note on Cleanup code default style
-------------------------------------
-
-Previously, if not defined, the cleanup style was determined automatically
-from the compiler used, and one of the following was defined accordingly:
-
-	__CLEANUP_SEH	MSVC only
-	__CLEANUP_CXX	C++, including MSVC++, GNU G++
-	__CLEANUP_C		C, including GNU GCC, not MSVC
-
-These defines determine the style of cleanup (see pthread.h) and,
-most importantly, the way that cancelation and thread exit (via
-pthread_exit) is performed (see the routine ptw32_throw() in private.c).
-
-In short, the exceptions versions of the library throw an exception
-when a thread is canceled or exits (via pthread_exit()), which is
-caught by a handler in the thread startup routine, so that the
-the correct stack unwinding occurs regardless of where the thread
-is when it's canceled or exits via pthread_exit().
-
-In this snapshot, unless the build explicitly defines (e.g. via a
-compiler option) __CLEANUP_SEH, __CLEANUP_CXX, or __CLEANUP_C, then
-the build NOW always defaults to __CLEANUP_C style cleanup. This style
-uses setjmp/longjmp in the cancelation and pthread_exit implementations,
-and therefore won't do stack unwinding even when linked to applications
-that have it (e.g. C++ apps). This is for consistency with most/all
-commercial Unix POSIX threads implementations.
-
-Although it was not clearly documented before, it is still necessary to
-build your application using the same __CLEANUP_* define as was
-used for the version of the library that you link with, so that the
-correct parts of pthread.h are included. That is, the possible
-defines require the following library versions:
-
-	__CLEANUP_SEH	pthreadVSE.dll
-	__CLEANUP_CXX	pthreadVCE.dll or pthreadGCE.dll
-	__CLEANUP_C		pthreadVC.dll or pthreadGC.dll
-
-THE POINT OF ALL THIS IS: if you have not been defining one of these
-explicitly, then the defaults as described at the top of this
-section were being used.
-
-THIS NOW CHANGES, as has been explained above, but to try to make this
-clearer here's an example:
-
-If you were building your application with MSVC++ i.e. using C++
-exceptions (rather than SEH) and not explicitly defining one of
-__CLEANUP_*, then __CLEANUP_C++ was defined for you in pthread.h.
-You should have been linking with pthreadVCE.dll, which does
-stack unwinding.
-
-If you now build your application as you had before, pthread.h will now
-set __CLEANUP_C as the default style, and you will need to link
-with pthreadVC.dll. Stack unwinding will now NOT occur when a thread
-is canceled, or the thread calls pthread_exit().
-
-Your application will now most likely behave differently to previous
-versions, and in non-obvious ways. Most likely is that locally
-instantiated objects may not be destroyed or cleaned up after a thread
-is canceled.
-
-If you want the same behaviour as before, then you must now define
-__CLEANUP_C++ explicitly using a compiler option and link with
-pthreadVCE.dll as you did before.
-
-
-WHY ARE WE MAKING THE DEFAULT STYLE LESS EXCEPTION-FRIENDLY?
-Because no commercial Unix POSIX threads implementation allows you to
-choose to have stack unwinding. Therefore, providing it in pthread-win32
-as a default is dangerous. We still provide the choice but unless
-you consciously choose to do otherwise, your pthreads applications will
-now run or crash in similar ways irrespective of the threads platform
-you use. Or at least this is the hope.
-
-
-
-Building under VC++ using C++ EH, Structured EH, or just C
-----------------------------------------------------------
-
-From the source directory run one of the following:
-
-nmake clean VCE	(builds the VC++ C++ EH version pthreadVCE.dll)
-
-or:
-
-nmake clean VSE	(builds the VC++ structured EH version pthreadVSE.dll)
-
-or:
-
-nmake clean VC	(builds the VC setjmp/longjmp version of pthreadVC.dll)
-
-You can run the testsuite by changing to the "tests" directory and
-running the target corresponding to the DLL version you built:
-
-nmake clean VCE
-
-or:
-
-nmake clean VSE
-
-or:
-
-nmake clean VC
-
-or:
-
-nmake clean VCX	(tests the VC version of the library with C++ (EH)
-			 applications)
-
-
-Building under Mingw32
-----------------------
-
-The dll can be built with Mingw32 gcc-2.95.2-1 after you've
-made the changes to Mingw32 desribed in Question 6 of the FAQ.
-
-From the source directory, run
-
-make clean GCE
-
-or:
-
-make clean GC
-
-You can run the testsuite by changing to the "tests" directory and
-running
-
-make clean GCE
-
-or:
-
-make clean GC
-
-or:
-
-make clean GCX	(tests the GC version of the library with C++ (EH)
-			 applications)
-
-
-Building the library under Cygwin
----------------------------------
-
-Not tested by me although I think some people have done this.
-Not sure how successfully though.
-
-Cygwin is implementing it's own POSIX threads routines and these
-will be the ones to use if you develop using Cygwin.
-
-
-Ready to run binaries
----------------------
-
-For convenience, the following ready-to-run files can be downloaded
-from the FTP site (see under "Availability" below):
-
-	pthread.h
-	semaphore.h
-	sched.h
-	pthread.def
-	pthreadVCE.dll	- built with MSVC++ compiler using C++ EH
-	pthreadVCE.lib
-	pthreadVC.dll	- built with MSVC compiler using C setjmp/longjmp
-	pthreadVC.lib
-	pthreadVSE.dll	- built with MSVC compiler using SEH
-	pthreadVSE.lib
-	pthreadGCE.dll	- built with Mingw32 G++
-	pthreadGCE.a	- derived from pthreadGCE.dll
-	pthreadGC.dll	- built with Mingw32 GCC
-	pthreadGC.a	- derived from pthreadGC.dll
-        gcc.dll         - needed to build and run applications that use
-                          pthreadGCE.dll.
-
-
-Building applications with the library
---------------------------------------
-
-Use the appropriate DLL and LIB files to match the exception handing
-that you use in your application, or specifically, in your POSIX
-threads. Don't mix them or neither thread cancelation nor
-pthread_exit() will work reliably if at all.
-
-If in doubt use the C (no-exceptions) versions of the library.
-
-
-Building applications with GNU compilers
-----------------------------------------
-
-If you're using pthreadGCE.dll:
-
-Use gcc-2.95.2-1 or later modified as per pthreads-win32 FAQ question 11.
-
-With the three header files, pthreadGCE.dll, gcc.dll and libpthreadGCE.a
-in the same directory as your application myapp.c, you could compile,
-link and run myapp.c under Mingw32 as follows:
-
-	gcc -x c++ -o myapp.exe myapp.c -I. -L. -lpthreadGCE
-	myapp
-
-Or put pthreadGCE.dll and gcc.dll in an appropriate directory in
-your PATH, put libpthreadGCE.a in MINGW_ROOT\i386-mingw32\lib, and
-put the three header files in MINGW_ROOT\i386-mingw32\include,
-then use:
-
-	gcc -x c++ -o myapp.exe myapp.c -lpthreadGCE
-	myapp
-
-If you're using pthreadGC.dll:
-
-With the three header files, pthreadGC.dll and libpthreadGC.a in the
-same directory as your application myapp.c, you could compile, link
-and run myapp.c under Mingw32 as follows:
-
-	gcc -o myapp.exe myapp.c -I. -L. -lpthreadGC
-	myapp
-
-Or put pthreadGC.dll in an appropriate directory in your PATH,
-put libpthreadGC.a in MINGW_ROOT\i386-mingw32\lib, and
-put the three header files in MINGW_ROOT\i386-mingw32\include,
-then use:
-
-	gcc -o myapp.exe myapp.c -lpthreadGC
-	myapp
-
-
-Availability
-------------
-
-The complete source code in either unbundled, self-extracting
-Zip file, or tar/gzipped format can be found at:
-
-	ftp://sources.redhat.com/pub/pthreads-win32
-
-The pre-built DLL, export libraries and matching pthread.h can
-be found at:
-
-	ftp://sources.redhat.com/pub/pthreads-win32/dll-latest
-
-Home page:
-
-	http://sources.redhat.com/pthreads-win32/
-
-
-Mailing list
-------------
-
-There is a mailing list for discussing pthreads on Win32.
-To join, send email to:
-
-	pthreads-win32-subscribe@sources.redhat.com
-
-Unsubscribe by sending mail to:
-
-	pthreads-win32-unsubscribe@sources.redhat.com
-
-
-Acknowledgements
-----------------
-
-Pthreads-win32 is based substantially on a Win32 Pthreads
-implementation contributed by John E. Bossom.
-Many others have contributed important new code,
-improvements and bug fixes. Thanks go to Alexander Terekhov
-and Louis Thomas for their improvements to the implementation
-of condition variables.
-
-See the 'CONTRIBUTORS' file for the list of contributors.
-
-As much as possible, the ChangeLog file also attributes
-contributions and patches that have been incorporated
-in the library.
-
-----
-Ross Johnson
-<rpj@ise.canberra.edu.au>
-
-
-
-
-
-
-
-
+PTHREADS-WIN32

+==============

+

+Pthreads-win32 is free software, distributed under the GNU Lesser

+General Public License (LGPL). See the file 'COPYING.LIB' for terms

+and conditions. Also see the file 'COPYING' for information

+specific to pthreads-win32, copyrights and the LGPL.

+

+

+What is it?

+-----------

+

+Pthreads-win32 is an Open Source Software implementation of the

+Threads component of the POSIX 1003.1c 1995 Standard for Microsoft's

+Win32 environment. Some functions from POSIX 1003.1b are also

+supported including semaphores. Other related functions include

+the set of read-write lock functions. The library also supports

+some of the functionality of the Open Group's Single Unix

+specification, version 2, namely mutex types.

+

+See the file "ANNOUNCE" for more information including standards

+conformance details and list of supported routines.

+

+

+Which of the several dll versions to use?

+-----------------------------------------

+or,

+---

+What are all these pthread*.dll and pthread*.lib files?

+-------------------------------------------------------

+

+Simply, you only use one of them, but you need to choose carefully.

+

+The most important choice you need to make is whether to use a

+version that uses exceptions internally, or not (there are versions

+of the library that use exceptions as part of the thread

+cancelation and exit implementation, and one that uses

+setjmp/longjmp instead).

+

+There is some contension amongst POSIX threads experts as

+to how POSIX threads cancelation and exit should work

+with languages that include exceptions and handlers, e.g.

+C++ and even C (Microsoft's Structured Exceptions).

+

+The issue is: should cancelation of a thread in, say,

+a C++ application cause object destructors and C++ exception

+handlers to be invoked as the stack unwinds during thread

+exit, or not?

+

+There seems to be more opinion in favour of using the

+standard C version of the library (no EH) with C++ applications

+since this appears to be the assumption commercial pthreads

+implementations make. Therefore, if you use an EH version

+of pthreads-win32 then you may be under the illusion that

+your application will be portable, when in fact it is likely to

+behave very differently linked with other pthreads libraries.

+

+Now you may be asking: why have you kept the EH versions of

+the library?

+

+There are a couple of reasons:

+- there is division amongst the experts and so the code may

+  be needed in the future. (Yes, it's in the repository and we

+  can get it out anytime in the future, but ...)

+- pthreads-win32 is one of the few implementations, and possibly

+  the only freely available one, that has EH versions. It may be

+  useful to people who want to play with or study application

+  behaviour under these conditions.

+

+Finally, for a proper version of the library with no internal

+exceptions to be usable with C++ applications, the C version

+should compiled as C++ so that it knows about and can propagate

+exceptions even if it doesn't use C++ features.

+

+

+Notes:

+

+[If you use either pthreadVCE or pthreadGCE]

+

+1. [See also the discussion in the FAQ file - Q2, Q4, and Q5]

+

+Due to what is believed to be a C++ compliance error in VC++ whereby

+you may not have multiple handlers for the same exception in the same

+try/catch block, if your application contains catch(...) blocks in your POSIX

+threads then you will need to replace the "catch(...)" with the macro

+"PtW32Catch", eg.

+

+	#ifdef PtW32Catch

+		PtW32Catch {

+			...

+		}

+	#else

+		catch(...) {

+			...

+		}

+	#endif

+

+Otherwise neither pthreads cancelation nor pthread_exit() will work

+reliably when using versions of the library that use C++ exceptions

+for cancelation and thread exit.

+

+

+Library naming

+--------------

+

+Because the library is being built using various exception

+handling schemes and compilers - and because the library

+may not work reliably if these are mixed in an application,

+each different version of the library has it's own name.

+

+Note 1: the incompatibility is really between EH implementations

+of the different compilers. It should be possible to use the

+standard C version from either compiler with C++ applications

+built with a different compiler. If you use an EH version of

+the library, then you must use the same compiler for the

+application. This is another complication and dependency that

+can be avoided by using only the standard C library version.

+

+Note 2: if you use a standard C pthread*.dll with a C++

+application, then any functions that you define that are

+intended to be called via pthread_cleanup_push() must be

+__cdecl.

+

+Note 3: the intention is to also name either the VC or GC

+version (it should be arbitrary) as pthread.dll, including

+pthread.lib and libpthread.a as appropriate.

+

+In general:

+	pthread[VG]{SE,CE,C}.dll

+	pthread[VG]{SE,CE,C}.lib

+

+where:

+	[VG] indicates the compiler

+	V	- MS VC

+	G	- GNU C

+

+	{SE,CE,C} indicates the exception handling scheme

+	SE	- Structured EH

+	CE	- C++ EH

+	C	- no exceptions - uses setjmp/longjmp

+

+For example:

+	pthreadVSE.dll	(MSVC/SEH)

+	pthreadGCE.dll	(GNUC/C++ EH)

+	pthreadGC.dll	(GNUC/not dependent on exceptions)

+

+The GNU library archive file names have changed to:

+

+	libpthreadGCE.a

+	libpthreadGC.a

+

+

+Other name changes

+------------------

+

+All snapshots prior to and including snapshot 2000-08-13

+used "_pthread_" as the prefix to library internal

+functions, and "_PTHREAD_" to many library internal

+macros. These have now been changed to "ptw32_" and "PTW32_"

+respectively so as to not conflict with the ANSI standard's

+reservation of identifiers beginning with "_" and "__" for

+use by compiler implementations only.

+

+If you have written any applications and you are linking

+statically with the pthreads-win32 library then you may have

+included a call to _pthread_processInitialize. You will

+now have to change that to ptw32_processInitialize.

+

+

+A note on Cleanup code default style

+------------------------------------

+

+Previously, if not defined, the cleanup style was determined automatically

+from the compiler used, and one of the following was defined accordingly:

+

+	__CLEANUP_SEH	MSVC only

+	__CLEANUP_CXX	C++, including MSVC++, GNU G++

+	__CLEANUP_C		C, including GNU GCC, not MSVC

+

+These defines determine the style of cleanup (see pthread.h) and,

+most importantly, the way that cancelation and thread exit (via

+pthread_exit) is performed (see the routine ptw32_throw() in private.c).

+

+In short, the exceptions versions of the library throw an exception

+when a thread is canceled or exits (via pthread_exit()), which is

+caught by a handler in the thread startup routine, so that the

+the correct stack unwinding occurs regardless of where the thread

+is when it's canceled or exits via pthread_exit().

+

+In this snapshot, unless the build explicitly defines (e.g. via a

+compiler option) __CLEANUP_SEH, __CLEANUP_CXX, or __CLEANUP_C, then

+the build NOW always defaults to __CLEANUP_C style cleanup. This style

+uses setjmp/longjmp in the cancelation and pthread_exit implementations,

+and therefore won't do stack unwinding even when linked to applications

+that have it (e.g. C++ apps). This is for consistency with most/all

+commercial Unix POSIX threads implementations.

+

+Although it was not clearly documented before, it is still necessary to

+build your application using the same __CLEANUP_* define as was

+used for the version of the library that you link with, so that the

+correct parts of pthread.h are included. That is, the possible

+defines require the following library versions:

+

+	__CLEANUP_SEH	pthreadVSE.dll

+	__CLEANUP_CXX	pthreadVCE.dll or pthreadGCE.dll

+	__CLEANUP_C		pthreadVC.dll or pthreadGC.dll

+

+THE POINT OF ALL THIS IS: if you have not been defining one of these

+explicitly, then the defaults as described at the top of this

+section were being used.

+

+THIS NOW CHANGES, as has been explained above, but to try to make this

+clearer here's an example:

+

+If you were building your application with MSVC++ i.e. using C++

+exceptions (rather than SEH) and not explicitly defining one of

+__CLEANUP_*, then __CLEANUP_C++ was defined for you in pthread.h.

+You should have been linking with pthreadVCE.dll, which does

+stack unwinding.

+

+If you now build your application as you had before, pthread.h will now

+set __CLEANUP_C as the default style, and you will need to link

+with pthreadVC.dll. Stack unwinding will now NOT occur when a thread

+is canceled, or the thread calls pthread_exit().

+

+Your application will now most likely behave differently to previous

+versions, and in non-obvious ways. Most likely is that locally

+instantiated objects may not be destroyed or cleaned up after a thread

+is canceled.

+

+If you want the same behaviour as before, then you must now define

+__CLEANUP_C++ explicitly using a compiler option and link with

+pthreadVCE.dll as you did before.

+

+

+WHY ARE WE MAKING THE DEFAULT STYLE LESS EXCEPTION-FRIENDLY?

+Because no commercial Unix POSIX threads implementation allows you to

+choose to have stack unwinding. Therefore, providing it in pthread-win32

+as a default is dangerous. We still provide the choice but unless

+you consciously choose to do otherwise, your pthreads applications will

+now run or crash in similar ways irrespective of the threads platform

+you use. Or at least this is the hope.

+

+

+

+Building under VC++ using C++ EH, Structured EH, or just C

+----------------------------------------------------------

+

+From the source directory run one of the following:

+

+nmake clean VCE (builds the VC++ C++ EH version pthreadVCE.dll)

+

+or:

+

+nmake clean VSE (builds the VC++ structured EH version pthreadVSE.dll)

+

+or:

+

+nmake clean VC	(builds the VC setjmp/longjmp version of pthreadVC.dll)

+

+You can run the testsuite by changing to the "tests" directory and

+running the target corresponding to the DLL version you built:

+

+nmake clean VCE

+

+or:

+

+nmake clean VSE

+

+or:

+

+nmake clean VC

+

+or:

+

+nmake clean VCX (tests the VC version of the library with C++ (EH)

+			 applications)

+

+

+Building under Mingw32

+----------------------

+

+The dll can be built with Mingw32 gcc-2.95.2-1 after you've

+made the changes to Mingw32 desribed in Question 6 of the FAQ.

+

+From the source directory, run

+

+make clean GCE

+

+or:

+

+make clean GC

+

+You can run the testsuite by changing to the "tests" directory and

+running

+

+make clean GCE

+

+or:

+

+make clean GC

+

+or:

+

+make clean GCX	(tests the GC version of the library with C++ (EH)

+			 applications)

+

+

+Building the library under Cygwin

+---------------------------------

+

+Not tested by me although I think some people have done this.

+Not sure how successfully though.

+

+Cygwin is implementing it's own POSIX threads routines and these

+will be the ones to use if you develop using Cygwin.

+

+

+Ready to run binaries

+---------------------

+

+For convenience, the following ready-to-run files can be downloaded

+from the FTP site (see under "Availability" below):

+

+	pthread.h

+	semaphore.h

+	sched.h

+	pthread.def

+	pthreadVCE.dll	- built with MSVC++ compiler using C++ EH

+	pthreadVCE.lib

+	pthreadVC.dll	- built with MSVC compiler using C setjmp/longjmp

+	pthreadVC.lib

+	pthreadVSE.dll	- built with MSVC compiler using SEH

+	pthreadVSE.lib

+	pthreadGCE.dll	- built with Mingw32 G++

+	pthreadGCE.a	- derived from pthreadGCE.dll

+	pthreadGC.dll	- built with Mingw32 GCC

+	pthreadGC.a	- derived from pthreadGC.dll

+	gcc.dll 	- needed to build and run applications that use

+			  pthreadGCE.dll.

+

+

+Building applications with the library

+--------------------------------------

+

+Use the appropriate DLL and LIB files to match the exception handing

+that you use in your application, or specifically, in your POSIX

+threads. Don't mix them or neither thread cancelation nor

+pthread_exit() will work reliably if at all.

+

+If in doubt use the C (no-exceptions) versions of the library.

+

+

+Building applications with GNU compilers

+----------------------------------------

+

+If you're using pthreadGCE.dll:

+

+Use gcc-2.95.2-1 or later modified as per pthreads-win32 FAQ question 11.

+

+With the three header files, pthreadGCE.dll, gcc.dll and libpthreadGCE.a

+in the same directory as your application myapp.c, you could compile,

+link and run myapp.c under Mingw32 as follows:

+

+	gcc -x c++ -o myapp.exe myapp.c -I. -L. -lpthreadGCE

+	myapp

+

+Or put pthreadGCE.dll and gcc.dll in an appropriate directory in

+your PATH, put libpthreadGCE.a in MINGW_ROOT\i386-mingw32\lib, and

+put the three header files in MINGW_ROOT\i386-mingw32\include,

+then use:

+

+	gcc -x c++ -o myapp.exe myapp.c -lpthreadGCE

+	myapp

+

+If you're using pthreadGC.dll:

+

+With the three header files, pthreadGC.dll and libpthreadGC.a in the

+same directory as your application myapp.c, you could compile, link

+and run myapp.c under Mingw32 as follows:

+

+	gcc -o myapp.exe myapp.c -I. -L. -lpthreadGC

+	myapp

+

+Or put pthreadGC.dll in an appropriate directory in your PATH,

+put libpthreadGC.a in MINGW_ROOT\i386-mingw32\lib, and

+put the three header files in MINGW_ROOT\i386-mingw32\include,

+then use:

+

+	gcc -o myapp.exe myapp.c -lpthreadGC

+	myapp

+

+

+Availability

+------------

+

+The complete source code in either unbundled, self-extracting

+Zip file, or tar/gzipped format can be found at:

+

+	ftp://sources.redhat.com/pub/pthreads-win32

+

+The pre-built DLL, export libraries and matching pthread.h can

+be found at:

+

+	ftp://sources.redhat.com/pub/pthreads-win32/dll-latest

+

+Home page:

+

+	http://sources.redhat.com/pthreads-win32/

+

+

+Mailing list

+------------

+

+There is a mailing list for discussing pthreads on Win32.

+To join, send email to:

+

+	pthreads-win32-subscribe@sources.redhat.com

+

+Unsubscribe by sending mail to:

+

+	pthreads-win32-unsubscribe@sources.redhat.com

+

+

+Acknowledgements

+----------------

+

+Pthreads-win32 is based substantially on a Win32 Pthreads

+implementation contributed by John E. Bossom.

+Many others have contributed important new code,

+improvements and bug fixes. Thanks go to Alexander Terekhov

+and Louis Thomas for their improvements to the implementation

+of condition variables.

+

+See the 'CONTRIBUTORS' file for the list of contributors.

+

+As much as possible, the ChangeLog file also attributes

+contributions and patches that have been incorporated

+in the library.

+

+----

+Ross Johnson

+<rpj@ise.canberra.edu.au>

+

+

+

+

+

+

+

+