|author||Ivan Maidanski <firstname.lastname@example.org>||2011-07-26 14:56:55 +0200|
|committer||Ivan Maidanski <email@example.com>||2011-07-26 15:03:41 +0200|
gc6.0 tarball importgc6_0
Diffstat (limited to 'README.QUICK')
1 files changed, 57 insertions, 15 deletions
diff --git a/README.QUICK b/README.QUICK
index ddebf82..8294a87 100644
@@ -1,7 +1,7 @@
Copyright 1988, 1989 Hans-J. Boehm, Alan J. Demers
Copyright (c) 1991-1995 by Xerox Corporation. All rights reserved.
Copyright (c) 1996-1999 by Silicon Graphics. All rights reserved.
-Copyright (c) 1999 by Hewlett-Packard. All rights reserved.
+Copyright (c) 1999-2001 by Hewlett-Packard. All rights reserved.
THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY EXPRESSED
OR IMPLIED. ANY USE IS AT YOUR OWN RISK.
@@ -12,32 +12,74 @@ Permission to modify the code and to distribute modified code is granted,
provided the above notices are retained, and a notice that the code was
modified is included with the above copyright notice.
+A few files have other copyright holders. A few of the files needed
+to use the GNU-style build procedure come with a modified GPL license
+that appears not to significantly restrict use of the collector, though
+use of those files for a purpose other than building the collector may
+require the resulting code to be covered by the GPL.
For more details and the names of other contributors, see the
-README file and gc.h. This file describes typical use of
+doc/README* files and include/gc.h. This file describes typical use of
the collector on a machine that is already supported.
+For the version number, see doc/README or version.h.
-Under UN*X, type "make test". Under OS/2 or Windows NT, copy the
-appropriate makefile to MAKEFILE, read it, and type "nmake test".
-Read the machine specific README if one exists. The only way to
-develop code with the collector for Windows 3.1 is to develop under
-Windows NT, and then to use win32S.
+Under UN*X, Linux:
+Alternative 1 (the old way): type "make test" in this directory.
+ Link against gc.a.
+Alternative 2 (the new way): type
+ "./configure --prefix=<dir>; make; make check; make install".
+ Link against <dir>/lib/libgc.a or <dir>/lib/libgc.so.
+ See README.autoconf for details
+Under OS/2 or Windows 95, 98, Me, NT, or 2000:
+copy the appropriate makefile to MAKEFILE, read it, and type "nmake test".
+(Under Windows, this assumes you have Microsoft command-line tools
+installed, and have DOS configured with enough environment space to run them.)
+Read the machine specific README in the doc directory if one exists.
+The only way to develop code with the collector for Windows 3.1 is
+to develop under Windows NT or 95+, and then to use win32S.
+If you need thread support, you will need to either follow the special
+platform-dependent instructions (win32), or add a suitable define
+option as described in Makefile.
-If you wish to use the cord (structured string) library type
+If you wish to use the cord (structured string) library, type
"make cords". (This requires an ANSI C compiler. You may need
-to redefine CC in the Makefile.)
+to redefine CC in the Makefile. The CORD_printf implementation in
+cordprnt.c is known to be less than perfectly portable. The rest
+of the package should still work.)
If you wish to use the collector from C++, type
"make c++". These add further files to gc.a and to the include
-subdirectory. See cord/cord.h and gc_c++.h.
+subdirectory. See cord/cord.h and include/gc_cpp.h.
-Include "gc.h" from this directory. Link against the appropriate library
-("gc.a" under UN*X). Replace calls to malloc by calls to GC_MALLOC,
-and calls to realloc by calls to GC_REALLOC. If the object is known
-to never contain pointers, use GC_MALLOC_ATOMIC instead of
+Include "gc.h" from the include subdirectory. Link against the
+appropriate library ("gc.a" under UN*X). Replace calls to malloc
+by calls to GC_MALLOC, and calls to realloc by calls to GC_REALLOC.
+If the object is known to never contain pointers, use GC_MALLOC_ATOMIC
+instead of GC_MALLOC.
Define GC_DEBUG before including gc.h for additional checking.
+More documentation on the collector interface can be found at
+in doc/README, and in include/gc.h .
+Do not store the only pointer to an object in memory allocated
+with system malloc, since the collector usually does not scan
+memory allocated in this way.
+Use with threads may be supported on your system, but requires the
+collector to be built with thread support. See Makefile. The collector
+does not guarantee to scan thread-local storage (e.g. of the kind
+accessed with pthread_getspecific()). The collector does scan
+thread stacks though, so generally the best solution is to ensure that
+any pointers stored in thread-local storage are also stored on the
+thread's stack for the duration of their lifetime.