diff options
Diffstat (limited to 'pthreads/README')
| -rw-r--r-- | pthreads/README | 477 |
1 files changed, 252 insertions, 225 deletions
diff --git a/pthreads/README b/pthreads/README index 545360bfa..9e9bb8103 100644 --- a/pthreads/README +++ b/pthreads/README @@ -10,15 +10,14 @@ 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 (or later) -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 +Pthreads-win32 (a.k.a. pthreads4w) is an Open Source Software +implementation of the Threads component of the POSIX 1003.1c 1995 +Standard (or later) for Microsoft's Windows 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, -plus some common and pthreads-win32 specific non-portable -routines (see README.NONPORTABLE). +Group's Single Unix specification, namely mutex types, plus some common +and pthreads-win32 specific non-portable routines (see README.NONPORTABLE). See the file "ANNOUNCE" for more information including standards conformance details and the list of supported and unsupported @@ -27,15 +26,15 @@ routines. Prerequisites ------------- -MSVC or GNU C (MinGW32 MSys development kit) +MSVC or GNU C (MinGW32 or MinGW64 MSys development kit) To build from source. QueueUserAPCEx by Panagiotis E. Hadjidoukas - To support any thread cancelation in C++ library builds or - to support cancelation of blocked threads in any build. + To support any thread cancellation in C++ library builds or + to support cancellation of blocked threads in any build. This library is not required otherwise. - For true async cancelation of threads (including blocked threads). + For true async cancellation of threads (including blocked threads). This is a DLL and Windows driver that provides pre-emptive APC by forcing threads into an alertable state when the APC is queued. Both the DLL and driver are provided with the pthreads-win32.exe @@ -47,7 +46,7 @@ QueueUserAPCEx by Panagiotis E. Hadjidoukas Pthreads-win32 will automatically detect if the QueueUserAPCEx DLL QuserEx.DLL is available and whether the driver AlertDrv.sys is loaded. If it is not available, pthreads-win32 will simulate async - cancelation, which means that it can async cancel only threads that + cancellation, which means that it can async cancel only threads that are runnable. The simulated async cancellation cannot cancel blocked threads. @@ -64,6 +63,11 @@ 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. +Please do not distribute your own modified versions of the library +using names conforming to this description. You can use the +makefile variable "EXTRAVERSION" to append your own suffix to the +library names when building and testing your library. + 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 @@ -82,80 +86,85 @@ version (it should be arbitrary) as pthread.dll, including pthread.lib and libpthread.a as appropriate. This is no longer likely to happen. -Note 4: the compatibility number was added so that applications -can differentiate between binary incompatible versions of the -libs and dlls. +Note 4: the compatibility number (major version number) was +added so that applications can differentiate between binary +incompatible versions of the libs and dlls. -In general: - pthread[VG]{SE,CE,C}[c].dll - pthread[VG]{SE,CE,C}[c].lib +In general the naming format used is: + pthread[VG]{SE,CE,C}[c][E].dll + pthread[VG]{SE,CE,C}[c][E].lib where: - [VG] indicates the compiler - V - MS VC, or - G - GNU C + [VG] indicates the compiler + V - MS VC, or + G - GNU C - {SE,CE,C} indicates the exception handling scheme - SE - Structured EH, or - CE - C++ EH, or - C - no exceptions - uses setjmp/longjmp + {SE,CE,C} indicates the exception handling scheme + SE - Structured EH, or + CE - C++ EH, or + C - no exceptions - uses setjmp/longjmp - c - DLL compatibility number indicating ABI and API - compatibility with applications built against - a snapshot with the same compatibility number. - See 'Version numbering' below. + c - DLL major version number indicating ABI + compatibility with applications built against + a snapshot with the same major version number. + See 'Version numbering' below. + E - EXTRAVERSION suffix. The name may also be suffixed by a 'd' to indicate a debugging version -of the library. E.g. pthreadVC2d.lib. Debugging versions contain -additional information for debugging (symbols etc) and are often not -optimised in any way (compiled with optimisation turned off). +of the library. E.g. pthreadVC2d.lib. These will be created e.g. when +the *-debug makefile targets are used. Examples: - pthreadVSE.dll (MSVC/SEH) - pthreadGCE.dll (GNUC/C++ EH) - pthreadGC.dll (GNUC/not dependent on exceptions) - pthreadVC1.dll (MSVC/not dependent on exceptions - not binary - compatible with pthreadVC.dll) - pthreadVC2.dll (MSVC/not dependent on exceptions - not binary - compatible with pthreadVC1.dll or pthreadVC.dll) + pthreadVC2.dll (MSVC/not dependent on exceptions - not binary + compatible with pthreadVC1.dll or pthreadVC.dll) + pthreadGC2-w32.dll (As built, e.g., by "make GC ARCH=-m32 EXTRAVERSION=-w32") + pthreadVC2-w64.dll (As built, e.g., by "nmake VC ARCH=-m64 EXTRAVERSION=-w64") -The GNU library archive file names have correspondingly changed to: +For information on ARCH (MinGW GNUmakefile) or TARGET_CPU (MSVS Makefile) +see the respective "Building with ..." sections below. - libpthreadGCEc.a - libpthreadGCc.a +The GNU library archive file names have correspondingly changed, e.g.: + libpthreadGCE2.a + libpthreadGC2.a + libpthreadGC2-w64.a -Versioning numbering --------------------- -Version numbering is separate from the snapshot dating system, and -is the canonical version identification system embedded within the -DLL using the Microsoft version resource system. The versioning -system chosen follows the GNU Libtool system. See -http://www.gnu.org/software/libtool/manual.html section 6.2. +Version numbering +----------------- -See the resource file 'version.rc'. +See pthread.h and the resource file 'version.rc'. Microsoft version numbers use 4 integers: 0.0.0.0 -Pthreads-win32 uses the first 3 following the Libtool convention. +Pthreads-win32 uses the first 3 following the standard major.minor.micro +system. We had claimed to follow the Libtool convention but this has +not been the case with recent releases. Binary compatibility and +consequently library file naming has not changed over this time either +so it should not cause any problems. + The fourth is commonly used for the build number, but will be reserved for future use. - current.revision.age.0 + major.minor.micro.0 The numbers are changed as follows: -1. If the library source code has changed at all since the last update, - then increment revision (`c:r:a' becomes `c:r+1:a'). -2. If any interfaces have been added, removed, or changed since the last - update, increment current, and set revision to 0. -3. If any interfaces have been added since the last public release, then - increment age. -4. If any interfaces have been removed or changed since the last public - release, then set age to 0. +1. If the general binary interface (ABI) has changed at all since the + last update in a way that requires recompilation and relinking of + applications, then increment Major, and set both minor and micro to 0. + (`M:m:u' becomes `M+1:0:0') +2. If the general API has changed at all since the last update or + there have been semantic/behaviour changes (bug fixes etc) but does + not require recompilation of existing applications, then increment + minor and set micro to 0. + (`M:m:u' becomes `M:m+1:0') +3. If there have been no interface or semantic changes since the last + public release but a new release is deemed necessary for some reason, + then increment micro. + (`M:m:u' becomes `M:m:u+1') DLL compatibility numbering is an attempt to ensure that applications @@ -167,13 +176,10 @@ this inevitably requires incompatible versions of the same DLLs to have different names. Pthreads-win32 has adopted the Cygwin convention of appending a single -integer number to the DLL name. The number used is based on the library -version number and is computed as 'current' - 'age'. - -(See http://home.att.net/~perlspinr/libversioning.html for a nicely -detailed explanation.) +integer number to the DLL name. The number used is simply the library's +major version number. -Using this method, DLL name/s will only change when the DLL's +Consequently, DLL name/s will only change when the DLL's backwards compatibility changes. Note that the addition of new 'interfaces' will not of itself change the DLL's compatibility for older applications. @@ -186,51 +192,18 @@ or, What are all these pthread*.dll and pthread*.lib files? ------------------------------------------------------- -Simple, use either pthreadGCv.* if you use GCC, or pthreadVCv.* if you -use MSVC - where 'v' is the DLL versioning (compatibility) number. +Simple, use either pthreadGCc.* if you use GCC, or pthreadVCc.* if you +use MSVC - where 'c' is the DLL versioning (compatibility) number. Otherwise, you need to choose carefully and know WHY. 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. The default version uses +cancellation and exit implementation. The default version uses setjmp/longjmp. -There is some contension amongst POSIX threads experts as -to how POSIX threads cancelation and exit should work -with languages that use exceptions, 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 -for the reason that 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 differently when linked with other pthreads libraries. - -Now you may be asking: then 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 it would be difficult - to find. -- 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. - -Notes: - -[If you use either pthreadVCE or pthreadGCE] +If you use either pthreadVCE or pthreadGCE: 1. [See also the discussion in the FAQ file - Q2, Q4, and Q5] @@ -248,13 +221,9 @@ threads then you will need to replace the "catch(...)" with the macro } #endif -Otherwise neither pthreads cancelation nor pthread_exit() will work +Otherwise neither pthreads cancellation nor pthread_exit() will work reliably when using versions of the library that use C++ exceptions -for cancelation and thread exit. - -This is 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. GNU G++ doesn't have this restriction. +for cancellation and thread exit. Other name changes @@ -285,7 +254,7 @@ from the compiler used, and one of the following was defined accordingly: __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 +most importantly, the way that cancellation and thread exit (via pthread_exit) is performed (see the routine ptw32_throw()). In short, the exceptions versions of the library throw an exception @@ -297,7 +266,7 @@ 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, +uses setjmp/longjmp in the cancellation 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. @@ -329,104 +298,185 @@ now run or crash in similar ways irrespective of the pthreads platform you use. Or at least this is the hope. -Building under VC++ using C++ EH, Structured EH, or just C ----------------------------------------------------------- +Development Build Toolchains and Configurations +----------------------------------------------- + +As of Release 2.10 all build configurations pass the full test suite +for the following toolchains and configurations: + +DLL and static library (full inlined and small) builds: +VC, VCE, VSE +GC, GCE + +MSVS: +Intel Core i7 (6 Core HT) +Windows 7 64 bit +MSVS 2010 Express with SDK 7.1 (using the SDK command shell) +TARGET_CPU = x64 and x86 + +GNU: +Intel Core i7 (6 Core HT) +Windows 7 64 bit +MinGW64 multilib enabled +ARCH = -m32 and -m64 + + +Building with MS Visual Studio (C, VC++ using C++ EH, or Structured EH) +----------------------------------------------------------------------- From the source directory run nmake without any arguments to list help information. E.g. $ nmake -Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 -Copyright (C) Microsoft Corp 1988-1998. All rights reserved. +As examples, as at Release 2.10 the pre-built DLLs and static libraries +are built from the following command-lines: + +[Note: "setenv" comes with the SDK. "/2003" is used to override my build +system which is Win7 (at the time of writing) for backwards compatibility.] + +$ setenv /x64 /2003 /Release +$ nmake realclean VC +$ nmake realclean VCE +$ nmake realclean VSE +$ nmake realclean VC-static +$ nmake realclean VCE-static +$ nmake realclean VSE-static +$ setenv /x86 /2003 /Release +$ nmake realclean VC +$ nmake realclean VCE +$ nmake realclean VSE +$ nmake realclean VC-static +$ nmake realclean VCE-static +$ nmake realclean VSE-static -Run one of the following command lines: -nmake clean VCE (to build the MSVC dll with C++ exception handling) -nmake clean VSE (to build the MSVC dll with structured exception handling) -nmake clean VC (to build the MSVC dll with C cleanup code) -nmake clean VCE-inlined (to build the MSVC inlined dll with C++ exception handling) -nmake clean VSE-inlined (to build the MSVC inlined dll with structured exception handling) -nmake clean VC-inlined (to build the MSVC inlined dll with C cleanup code) -nmake clean VC-static (to build the MSVC static lib with C cleanup code) -nmake clean VCE-debug (to build the debug MSVC dll with C++ exception handling) -nmake clean VSE-debug (to build the debug MSVC dll with structured exception handling) -nmake clean VC-debug (to build the debug MSVC dll with C cleanup code) -nmake clean VCE-inlined-debug (to build the debug MSVC inlined dll with C++ exception handling) -nmake clean VSE-inlined-debug (to build the debug MSVC inlined dll with structured exception handling) -nmake clean VC-inlined-debug (to build the debug MSVC inlined dll with C cleanup code) -nmake clean VC-static-debug (to build the debug MSVC static lib with C cleanup code) +If you want to differentiate between libraries by their names you can use, +e.g.: +$ nmake realclean VC EXTRAVERSION="-w64" -The pre-built dlls are normally built using the *-inlined targets. +The string provided via the variable EXTRAVERSION is appended to the dll +and .lib library names, e.g.: + +pthreadVC2-w64.dll +pthreadVC2-w64.lib + +To build and test all DLLs and static lib compatibility versions +(VC, VCE, VSE): + +[Note that the EXTRAVERSION="..." option is passed to the tests Makefile +when you target "all-tests". If you change to the tests directory and +run the tests you will need to repeat the option explicitly to the test +"nmake" command-line.] + +$ setenv /x64 /2003 /release +$ nmake all-tests You can run the testsuite by changing to the "tests" directory and running nmake. E.g.: $ cd tests -$ nmake +$ nmake VC + +For failure analysis etc. individual tests can be built +and run, e.g: -Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 -Copyright (C) Microsoft Corp 1988-1998. All rights reserved. +$ cd tests +$ nmake VC TESTS="foo bar" + +This builds and runs all prerequisite tests as well as the individual +tests listed. Prerequisite tests are defined in tests\runorder.mk. + +To build and run only those tests listed use, i.e. without the +additional prerequistite dependency tests: -Run one of the following command lines: -nmake clean VC (to test using VC dll with VC (no EH) applications) -nmake clean VCX (to test using VC dll with VC++ (EH) applications) -nmake clean VCE (to test using the VCE dll with VC++ EH applications) -nmake clean VSE (to test using VSE dll with VC (SEH) applications) -nmake clean VC-bench (to benchtest using VC dll with C bench app) -nmake clean VCX-bench (to benchtest using VC dll with C++ bench app) -nmake clean VCE-bench (to benchtest using VCE dll with C++ bench app) -nmake clean VSE-bench (to benchtest using VSE dll with SEH bench app) -nmake clean VC-static (to test using VC static lib with VC (no EH) applications) +$ cd tests +$ nmake VC NO_DEPS=1 TESTS="foo bar" -Building under Mingw32 ----------------------- +Building with MinGW +------------------- -The dll can be built easily with recent versions of Mingw32. -(The distributed versions are built using Mingw32 and MsysDTK -from www.mingw32.org.) +Please use Mingw64 to build either 64 or 32 bit variants of the DLL that will +run on 64 bit systems. We have found that Mingw32 builds of the GCE library +variants fail when run on 64 bit systems. -From the source directory, run make for help information. E.g.: +From the source directory, run 'make' without arguments for help information. $ make -Run one of the following command lines: -make clean GC (to build the GNU C dll with C cleanup code) -make clean GCE (to build the GNU C dll with C++ exception handling) -make clean GC-inlined (to build the GNU C inlined dll with C cleanup code) -make clean GCE-inlined (to build the GNU C inlined dll with C++ exception handling) -make clean GC-static (to build the GNU C inlined static lib with C cleanup code) -make clean GC-debug (to build the GNU C debug dll with C cleanup code) -make clean GCE-debug (to build the GNU C debug dll with C++ exception handling) -make clean GC-inlined-debug (to build the GNU C inlined debug dll with C cleanup code) -make clean GCE-inlined-debug (to build the GNU C inlined debug dll with C++ exception handling) -make clean GC-static-debug (to build the GNU C inlined static debug lib with C cleanup code) +With MinGW64 multilib installed the following variables can be defined +either on the make command line or in the shell environment: + +ARCH + - possible values are "-m64" and "-m32". You will probably recognise + these as gcc flags however the GNUmakefile also converts these into + the appropriate windres options when building version.o. + +As examples, as at Release 2.10 the pre-built DLLs and static libraries +are built from the following command-lines: -The pre-built dlls are normally built using the *-inlined targets. +$ nmake realclean GC ARCH=-m64 +$ nmake realclean GC ARCH=-m32 +$ nmake realclean GCE ARCH=-m64 +$ nmake realclean GCE ARCH=-m32 +$ nmake realclean GC-static ARCH=-m64 +$ nmake realclean GC-static ARCH=-m32 +$ nmake realclean GCE-static ARCH=-m64 +$ nmake realclean GCE-static ARCH=-m32 + +If you want to differentiate between libraries by their names you can use, +e.g.: + +$ make realclean GC ARCH="-m64" EXTRAVERSION="-w64" + +The string provided via the variable EXTRAVERSION is appended to the dll +and .a library names, e.g.: + +pthreadGC2-w64.dll +libpthreadGC2-w64.a + +To build and test all DLLs and static lib compatibility variants (GC, GCE): + +Note that the ARCH="..." and/or EXTRAVERSION="..." options are passed to the +tests GNUmakefile when you target "all-tests". If you change to the tests +directory and run the tests you will need to repeat those options explicitly +to the test "make" command-line. + +$ make all-tests +or, with MinGW64 (multilib enabled): +$ make all-tests ARCH=-m64 +$ make all-tests ARCH=-m32 You can run the testsuite by changing to the "tests" directory and -running make for help information. E.g.: +running make. E.g.: $ cd tests -$ make -Run one of the following command lines: -make clean GC (to test using GC dll with C (no EH) applications) -make clean GCX (to test using GC dll with C++ (EH) applications) -make clean GCE (to test using GCE dll with C++ (EH) applications) -make clean GC-bench (to benchtest using GNU C dll with C cleanup code) -make clean GCE-bench (to benchtest using GNU C dll with C++ exception handling) -make clean GC-static (to test using GC static lib with C (no EH) applications) +$ make GC + +For failure analysis etc. individual tests can be built and run, e.g: +$ cd tests +$ make GC TESTS="foo bar" + +This builds and runs all prerequisite tests as well as the individual +tests listed. Prerequisite tests are defined in tests\runorder.mk. -Building under Linux using the Mingw32 cross development tools --------------------------------------------------------------- +To build and run only those tests listed use, i.e. without the additional +prerequistite dependency tests: -You can build the library without leaving Linux by using the Mingw32 cross -development toolchain. See http://www.libsdl.org/extras/win32/cross/ for -tools and info. The GNUmakefile contains some support for this, for example: +$ cd tests +$ make GC NO_DEPS=1 TESTS="foo bar" -make CROSS=i386-mingw32msvc- clean GC-inlined + +Building under Linux using the MinGW cross development tools +------------------------------------------------------------ + +You can build the library on Linux by using the MinGW cross development +toolchain. See http://www.libsdl.org/extras/win32/cross/ for tools and +info. The GNUmakefile contains some support for this, for example: + +make CROSS=i386-mingw32msvc- clean GC will build pthreadGCn.dll and libpthreadGCn.a (n=version#), provided your cross-tools/bin directory is in your PATH (or use the cross-make.sh script @@ -449,30 +499,12 @@ MinGW32 (creates libpthreadGCn.a as a static link lib): make clean GC-static - -Define PTW32_STATIC_LIB when building your application. Also, your -application must call a two non-portable routines to initialise the -some state on startup and cleanup before exit. One other routine needs -to be called to cleanup after any Win32 threads have called POSIX API -routines. See README.NONPORTABLE or the html reference manual pages for -details on these routines: - -BOOL pthread_win32_process_attach_np (void); -BOOL pthread_win32_process_detach_np (void); -BOOL pthread_win32_thread_attach_np (void); // Currently a no-op -BOOL pthread_win32_thread_detach_np (void); - - -The tests makefiles have the same targets but only check that the -static library is statically linkable. They don't run the full -testsuite. To run the full testsuite, build the dlls and run the -dll test targets. - +Define PTW32_STATIC_LIB also when building your application. Building the library under Cygwin --------------------------------- -Cygwin is implementing it's own POSIX threads routines and these +Cygwin implements it's own POSIX threads routines and these will be the ones to use if you develop using Cygwin. @@ -485,39 +517,34 @@ from the FTP site (see under "Availability" below): pthread.h semaphore.h sched.h - pthreadVC.dll - built with MSVC compiler using C setjmp/longjmp - pthreadVC.lib - pthreadVCE.dll - built with MSVC++ compiler using C++ EH - pthreadVCE.lib - pthreadVSE.dll - built with MSVC compiler using SEH - pthreadVSE.lib - pthreadGC.dll - built with Mingw32 GCC - libpthreadGC.a - derived from pthreadGC.dll - pthreadGCE.dll - built with Mingw32 G++ - libpthreadGCE.a - derived from pthreadGCE.dll - -As of August 2003 pthreads-win32 pthreadG* versions are built and tested -using the MinGW + MsysDTK environment current as of that date or later. -The following file MAY be needed for older MinGW environments. - - gcc.dll - needed to build and run applications that use - pthreadGCE.dll. - + pthreadVC2.dll - built with MSVC compiler using C setjmp/longjmp + pthreadVC2.lib + pthreadVCE2.dll - built with MSVC++ compiler using C++ EH + pthreadVCE2.lib + pthreadVSE2.dll - built with MSVC compiler using SEH + pthreadVSE2.lib + pthreadGC2.dll - built with Mingw32 GCC + libpthreadGC2.a - derived from pthreadGC.dll + pthreadGCE2.dll - built with Mingw32 G++ + libpthreadGCE2.a - derived from pthreadGCE.dll + +You may also need to include runtime DLLs from your SDK when +distributing your applications. Building applications with GNU compilers ---------------------------------------- -If you're using pthreadGC.dll: +If you're using pthreadGC2.dll: -With the three header files, pthreadGC.dll and libpthreadGC.a in the +With the three header files, pthreadGC2.dll and libpthreadGC2.a in the same directory as your application myapp.c, you could compile, link -and run myapp.c under Mingw32 as follows: +and run myapp.c under MinGW as follows: - gcc -o myapp.exe myapp.c -I. -L. -lpthreadGC + gcc -o myapp.exe myapp.c -I. -L. -lpthreadGC2 myapp -Or put pthreadGC.dll in an appropriate directory in your PATH, -put libpthreadGC.a in your system lib directory, and +Or put pthreadGC2.dll in an appropriate directory in your PATH, +put libpthreadGC2.a in your system lib directory, and put the three header files in your system include directory, then use: @@ -525,13 +552,13 @@ then use: myapp -If you're using pthreadGCE.dll: +If you're using pthreadGCE2.dll: -With the three header files, pthreadGCE.dll, gcc.dll and libpthreadGCE.a +With the three header files, pthreadGCE2.dll and libpthreadGCE2.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 + gcc -x c++ -o myapp.exe myapp.c -I. -L. -lpthreadGCE2 myapp Or put pthreadGCE.dll and gcc.dll in an appropriate directory in |