Re: [Gc] bogus installed gc_config_macros.h

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


 Hi Andy,

Sat,  9 Mar 2013, 20:56 +01:00 from Andy Wingo <wingo at pobox.com>:
>Hi,
>
>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
>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?

Regards,
Ivan

>
>
>Regards,
>
>Andy
>-- 
>http://wingolog.org/
>_______________________________________________
>Gc mailing list
>Gc at linux.hpl.hp.com
>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20130310/3819825b/attachment.htm


More information about the Gc mailing list