Re[6]: [Gc]: Problems with GC settings

Ivan Maidanski ivmai at
Mon Oct 5 23:28:10 PDT 2009


Juan Jose Garcia-Ripoll <juanjose.garciaripoll at> wrote:
> 2009/10/5 Ivan Maidanski <ivmai at>:
> > If your project is multi-threaded then GC_THREADS
> > is required to be defined before include "gc.h" (regardless
> > of options GC is built with); if you would try to link your
> >  multi-threaded program to a single-threaded GC lib,
> > I'll get a linkage error - this is the intended behavior (IMHO).
> Well, the difference is that my project may or may not be
> multithreaded, depending on what the user wants.

Essentially, this is the same as for GC lib.

> It is a compiler and
> the accompanying library. If the environment and operating system
> support threads, ok, otherwise, it builds single-threaded.

So, you export your lib features list (i.e. install your config.h along with your .lib or .so), right? (Otherwise, a client could be broken if it manipulates pointers in threads.)

> Same thing
> happens with other features in the garbage collector, such as
> incremental collection, the generational algorithm, parallel threads,
> etc, etc, It would be thus important to know what are the built in
> features of the garbage collector when one builds software using
> pre-installed libraries.
> Juanjo

The above list, may also include optimization level (-DPARALLEL_MARK is essentially an optimization algorithm) and the compiler version with which the installed GC lib is built.

In other words, you want access to the GC internal config (at build time of your project).

I think I understand - you want access to GC config.h along with libgc.a (or installed in the system. I'm not an expert in such things.

Another possible solution (which I'm personally use) is:
1. have GC lib distinct names: gc.lib is single-threaded and gcmt.lib is an MT-safe one;
2. build GC lib (of the required config) along with a project (so that GC would be an internal part of a project).


More information about the Gc mailing list