On 27 Nov 2012, at 21:28, green fox wrote: > Enviroment: > OS Windows7 , cygwin 1.7.14(0.260/5/3) , gcc 4.5.3 > Used ./configure --enable-threads --prefix=/usr --host=x86_64-w64-mingw32-gcc > > Problem: > Dies when compiling threads.cxx... with > threads.h:56:74: error: `_beginthread' was not declared in this scope > Due to headers for _beginthread() missing in some mingw packages. > MingW packages are supposed to have them.But current cygwin package > somehow does not have it. > Digging around cygwin mailing list, there appears to be fix on the > next release, however ETA is unknown. > Using gcc3 is a workaround, but defeats the whole purpose of > mingw-gcc4, and -mno-cygwin is long gone. > For the current situation, most likely one has pthread, so the logical option > is to use pthreads instead of the native _beginthread(). Am I on the > right track ?
It is possible, but I'd caution against that - fltk on WinXX is intended to run "native" and use Windows threads, not pthreads, so if you end up in a odd mix of Windows and "pretend-unix" runtime code, things can go awry... I gave up on cygwin a long time ago, switched to mingw, and never looked back. IFF you actually *need* the "pretend-unix" runtime that cygwin provides (e.g. if you are porting a large body of unix-specific code and you really, really, really need fork and pthreads and so forth) then cygwin is a good idea, but otherwise I'd bin it and do a mingw thing instead. Really... save yourself the pain... Though to be honest, it wasn't the poor compatibility that drove me away from cygwin, it was the performance; a long time ago we had a large cross-platform codebase, where the Win32 build was done with cygwin and it was dog slow... Some brief experiments with mingw showed it was about 3 times faster executing our code - we switched, and never went back. We never even bothered trying to scope out where the bottlenecks were, we just moved on... Sure, it is a bit more hassle in the code (we need to ifdef the Win32 stuff vs the unix stuff that linux and OSX use) but that turns out to be mostly trivial, and the resulting code works well everywhere. > > What would be the better option > > 1) Patch configure.in so that it has --enable-pthreads or such > Patch towards 1.3.1 ? or would it be better to do work on the 1.4/3.0? > 2) Fiddle with config.h for HAVE_PTHREAD_H 1 > 3) Throw away cygwin :-) Option 3 every time. > > My limited knowledge tells me that _beginthread() is defined in <process.h> > http://msdn.microsoft.com/en-gb/library/kdzttdcb%28VS.80%29.aspx > And looking at ./test/threads.h , under #elif defined(WIN32) && > !defined(__WATCOMC__) > we have #include <process.h> , so all is good. > We have > mingw64-x86_64-{gcc,gcc-core,gcc-g++,gcc-objc,headers,pthreads,runtime} > installed, good. > But we do not have _beginthread() anywhere. So I need a header for that, or > if we can use pthread,that can provide equlavant. The _beginthread() function is the Win32 equivalent to pthread_create(), and it should be in the Win32 header file process.h. If the version of process.h that your compiler provides (assuming it is meant to be emulating the MS headers of course!) does not provide _beginthread, then I'd hazard that it is broken, and should be discarded or fixed... _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
