add additional dependencies

modules/gdextensions/thirdparty/gc-8.2.2/README.QUICK.md

@@ -0,0 +1,85 @@
+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-2001 by Hewlett-Packard. All rights reserved.
+Copyright (c) 2009-2021 Ivan Maidanski
+
+THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY EXPRESSED
+OR IMPLIED.  ANY USE IS AT YOUR OWN RISK.
+
+Permission is hereby granted to use or copy this program
+for any purpose,  provided the above notices are retained on all copies.
+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.md,
+doc/README.*, AUTHORS and include/gc.h files.  These files describe typical
+use of the collector on a machine that is already supported.
+
+For the version number, see README.md or include/gc_version.h files.
+
+INSTALLATION:
+Under UN*X, Linux:
+Alternative 1 (the old way): type "make -f Makefile.direct check".
+        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 doc/README.autoconf for details
+
+Under Windows 95, 98, Me, NT, or 2000:
+copy the appropriate makefile to MAKEFILE, read it, and type "nmake check".
+(Under Windows, this assumes you have Microsoft command-line tools
+installed, and suitably configured.)
+Read the machine specific README.XXX in the doc directory if one exists.
+
+If you need thread support, you should define GC_THREADS as described in
+doc/README.macros (configure defines this implicitly unless --disable-threads
+option is given).
+
+If you wish to use the cord (structured string) library with the stand-alone
+Makefile.direct, type "make -f Makefile.direct cords".  (You may need to
+override CC specified 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.)  See include/cord.h for the API.
+
+If you wish to use the collector from C++, type "make c++", or use
+--enable-cplusplus with the configure script.  With Makefile.direct,
+"make c++" creates gccpp.a and gctba.a files (you should link with either
+gccpp.a or gctba.a).  With the alternate (preferred) build process, this
+generates libgccpp.a and libgctba.a, and/or libgccpp.so and libgctba.so.
+See include/gc_cpp.h and doc/gcinterface.md.
+
+TYPICAL USE:
+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 in README.md,
+doc/gcinterface.md, include/gc.h, and other files in the doc directory.
+
+WARNINGS:
+
+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.am or Makefile.direct.
+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.