Re: [Gc] bogus installed gc_config_macros.h
ivmai at mail.ru
Sat Mar 9 22:18:40 PST 2013
Sat, 9 Mar 2013, 20:56 +01:00 from Andy Wingo <wingo at pobox.com>:
>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
>gc_config_macros.h.in, and have AC_OUTPUT_FILES substitute in the
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 linux.hpl.hp.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gc