[Gc] Re: [bdwgc] Building with win32 threads on mingw / Windows 7
ivmai at mail.ru
Sun Dec 8 08:38:05 PST 2013
Below I assume either gc-7.4.0 release or at least rather recent gc-7.3alpha3 snapshot.
Mon, 7 Oct 2013, 16:05 -07:00 from Amos Wenger <notifications at github.com>:
>I'm having the problem exactly described here: https://email@example.com/msg00401.html
>Although the thread is from 2010, the problem still seems to be present.
>* I'm building on MinGW, with GCC 4.8.1, 32-bit platform, win32 thread model
>* I have bdwgc and libatomic_ops checked out from the latest version, and ran autoreconf -i on both of them with a recent autoconf (2.69) on another machine. Sorry, I don't have true MinGW environment (with bash, Make and autotools) on my PC - I have only mingw gcc (as well as mingw-w32/64 gcc). If you point me how to easily setup the environment exactly you have, I'd appreciate it.
>* When compiling after a ./configure --enable-threads=win32, none of the object files have any threading symbol in there (one would expect GC_CreateThread at 24 for example). It is strange as your config.h (if it is the one I observe in config.log) contains GC_WIN32_THREADS defined, right? You have posted your build log. Please check whether gcc is invoked with -DHAVE_CONFIG_H (especially for misc.c and win32_threads.c)
>* Trying to bypass that, ie. doing CPPFLAGS=-DWIN32_THREADS ./configure --enable-threads=win32 gives the appropriate symbols in win32_threads.o, as seen in this gist but then yields link errors, as seen in that gist .
WIN32_THREADS defines GC_WIN32_THREADS which, in turn, defines THREADS (in gcconfig.h) which should prevent definition of e.g. GC_do_blocking_inner in misc.c, so I don't see how the error could happen.
>The linker errors seem to be for those symbols in particular:
>* GC_check_finalizer_nested: defined in both finalizer.c and win32_threads.c
>* GC_do_blocking_inner: defined in both misc.c and win32_threads.c
>* GC_is_static_root: undefined reference in ptr_chck.c
>* GC_write_cs: undefined reference in win32_threads.c
>As for the first two, this happens because in those parts of misc.c and finalizer.c, the THREADS symbol doesn't seem to be defined, although it should be. Manually defining THREADS (e.g. adding -DTHREADS to CPPFLAGS) only brings more problems.
>Hence my questions:
>* Isn't --enable-threads=win32 supposed to produce a GC build with Win32 threads support? yes, it should produce
>* Why isn't THREADS defined for misc.c and finalizer.c?
Please send me build log (and config.h).
>* How do I get a Win32-threads-enabled build working at all? It should work as your expect but I have not tried it. I use either Cygwin or build the collector by direct invocation of gcc, e.g.:
gcc -I include -I libatomic_ops/src -DGC_THREADS -DGC_DLL -shared -o gc.dll extra/gc.c
gcc -I include -I libatomic_ops/src -DGC_THREADS -DGC_DLL tests/test.c gc.dll
>* Is the DllMain approach to watching new threads on Windows deprecated or can it still be used? It seems to be the easiest (although it requires distributing libgc-1.dll) It is supported but not recommended (as cannot support parallel marker and thread local allocations) and enabled by either compiling GC with GC_DISCOVER_TASK_THREADS or the client should invoke GC_use_threads_discovery (as in the above sample).
Here are the config.log for bdwgc and my GCC version information: https://gist.github.com/nddrylliog/97a67bc609215a363aff
>Thanks in advance for your time! I need more information (build log, config.h) to be able to find out what should be fixed.
>Reply to this email directly or view it on GitHub .
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gc