Re: [Gc] bogus installed gc_config_macros.h

Ivan Maidanski ivmai at
Sat Mar 9 22:18:40 PST 2013

 Hi Andy,

Sat,  9 Mar 2013, 20:56 +01:00 from Andy Wingo <wingo at>:
>I just cross-compiled libgc for mingw32, from a GNU/Linux system.  I
>compiled it --enable-threads=pthreads, to rely on pthreads-win32.
>However if in Guile I simply #define GC_THREADS and include <gc/gc.h>,
>it defaults to auto-detecting the kind of threads based on the current
>compiler and other heuristics, instead of using the thread support that
>I explicitly selected at compile-time.  In this case it chooses wrong,
>choosing win32 threads and not win32 pthreads.
CFLAGS=-DGC_WIN32_PTHREADS at client code compilation should solve the problem.
--enable-threads=pthreads at GC build time influences only which API to use for marker threads creation and whether GC_pthread_X functions are defined (i.e., GC_CreateThread and friends are defined in either case).

>The solution is probable to generate the #define GC_FOO_THREADS.  The
>easiest way is probably to just move gc_config_macros.h to
>, and have AC_OUTPUT_FILES substitute in the
>correct choices.
Currently, both gc and atomic_ops public API does not force the clients to run configure stuff. I don't think it's worth breaking this principle just because of mingw+pthread-win32 target (having CFLAGS=-DGC_WIN32_PTHREADS workaround for it).
Are there other solutions?


>Gc mailing list
>Gc at

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Gc mailing list