[Gc] Using LARGE_CONFIG flag (was: Too Many Heap Sections)

A.T.Hofkamp a.t.hofkamp at tue.nl
Wed Jan 4 04:07:28 PST 2006

Hello all,

First of all: Thank you Hans Boehm, for this wonderful library!!

The gc library is being used here in the runtime system of applications 
generated by our in-house compiler tool chain.

Installation of the gc library and its use are thus done by different persons 
from different machines.
All machines have the Linux operating system with Intel 32bit processors, 
although some use RedHat Fedora Core 3, and others use RedHat Enterprise 4. 
Both distributions use the same set of C libraries afaik.

One of the users of the compiler chain also had this 'Too many heap sections' 
problem, at the end of the application (the final output of the program did 

Lothar Scholz wrote:
> You must compile with LARGE_CONFIG defined. For version 6.6 this
> means:

We are currently using 6.5 . Maybe I should upgrade?

> The makefiles in the garbage collector must be patched so that the LARGE_CONFIG symbol is defined.
> This means that in the windows build file "gc.mak" we must add
> to line 118 (release build) and line 300 (debug build).

This is confusing to me.

Are you refering to makefiles of gc or to makefiles of the application being 
linked to gc?
In the former case, Makefiles are generated from ./configure, so it would seem 
that configure.ac should need to be changed instead, or am I missing something 

(in the latter case, I would just need to change the flags used to compile the 
generated applications).

Another thing that worries me with this flag is consistent use of it at both 
build times (ie at install-time of the gc lib, and at build-time of the 
application using gc-lib).
If the answer to the former question is 'change the make (or configure) of gc 
sources', then is it harmful if I define the LARGE_CONFIG symbol at 
install-time of the gc lib, and not at build-time of the application, or vice 
In particular, since the two above builds are in general performed at 
different machines by different users.

Thank you very much for your time,

More information about the Gc mailing list