> I am trying to run a simple(st) thread example in GTK with a > windows-MinGW-Msys development environment
Don't bother. You should not call GTK+ functions from multiple threads on Windows. It won't work. There are deep technical reasons for this, fixing it is in no way trivial. This has been mentioned several times over the years on this mailing list. Only call GTK+ functions from the thread (usually the "main" thread) that runs the GLib main loop, i.e. that calls gtk_main(). (Well, some limited (unknown) subset of GTK+ calls might work if called from other threads than the main thread. You have to experiment yourself.) > Mingw unfortunately doesnt provide thread headers > and libraries[pthread.h is unavailable]. Mingw provides the API for the native Win32 thread API and the Microsoft C library thread functions in its header just fine. That is what it should do. Mingw is not about POSIX emulation. The "p" in "pthread" stands for POSIX. That said, there does exist a good implementation of the pthread API to Windows. (It wraps the native Win32 thread API.) Google for pthreads-win32. You probably found it already? (That doesn't change the situation, though. Using GTK+ from multiple threads won't work on Windows no matter what API you use to create the threads.) But anyway, why don't you use the GThread API, which might be more natural in a GTK+ program. (But I repeat once more, using GTK+ from multiple threads won't work on Windows no matter what API you use to create the threads.) > I have copied the headers[pthread.h, sched.h > and semaphore.h] into the mingw include folder, and I have copied the > libraries for threads all into mingw lib folder. Without central package management (like on Linux), it is a bad idea to mix stuff from different origins in the same tree. Don't copy headers and libraries around so that you end up with a multitude of copies here and there. It will only confuse you later when you perhaps decide to upgrade to a fresher mingw and blow away the old mingw tree, forgetting that you had added other stuff there. Keep only what the mingw project distributes in the mingw tree, and things downloaded from other places in some systematic way in specific trees. Use -I and -L flags as appropriate when building, and set PATH when running. > I even use a -Lpath during compilation of my thread application. Well, d'oh. Using -L flags are a very basic thing. > Program compiles but the executable fails to link to the downloaded libraries > [which I have supplied in the -L and l options to gcc]. Do you know the difference between "import libraries" and DLLs? When using DLLs, the libraries you specify when linking with -l are (typically) import libraries. These aren't used at run time. The -L switch has no effect on where the executable looks for DLLs at run time. Nor has any other switch you can give at link time. Unlike most Unix systems, on Windows one can't store in an executable's header any run-time look-up path for shared libraries. > Message tells me "dll not found". You need to read up on how Windows locates DLLs required by a starting program. Hint: PATH. > I thought it might have something to do with registering the DLL with the > OS, and so I used regsvr32 to get DLL registered, but registration somehow > failed[I am not a geek and so I was not able to figure out why it failed]. Registering DLLs is related to COM and/or OLE, and has nothing to do with normal DLLs. > DISCLAIMER Please stop attaching multiple copies of the ridiculous disclaimer to your messages. It doesn't improve your credibility. --tml _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list