[Gc] bogus installed gc_config_macros.h
wingo at pobox.com
Sun Mar 10 10:08:04 PST 2013
On Sun 10 Mar 2013 07:18, Ivan Maidanski <ivmai at mail.ru> writes:
> CFLAGS=-DGC_WIN32_PTHREADS at client code compilation should solve the
It does, yes.
> --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).
I see, thank you.
> 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?
I'm not sure if I expressed myself well. I guess my point is, when you
configure bdw-gc, you select a configuration (most importantly, with
threads or without). This decision is visible to users of bdw-gc. It
would be nice if users didn't have to repeat themselves (e.g. by
defining GC_THREADS (and possibly also GC_WIN32_PTHREADS) before
#include <gc/gc.h>), because this choice was already made. Of course
you can initialize the collector without threads if you compiled with
threads, but that doesn't affect the interface (API/ABI) that bdw-gc was
configured to provide.
I have worked around this issue in Guile for the mingw case, so I guess
there is no urgent bug. But I still think it could be useful to
install a gc_config_macros.h that records the choices made at bdw-gc
compilation time, instead of the choices made when the user code
includes the bdw-gc headers.
More information about the Gc