\r
OBJS= $(XXXOBJS:XXX=)\r
\r
-all: gctest.exe de.exe test_cpp.exe\r
+all: gc.lib\r
+\r
+check: gctest.exe test_cpp.exe de.exe\r
+ gctest.exe\r
+ test_cpp.exe\r
\r
$(OBJS) test.obj: include\private\gc_priv.h include\private\gc_hdrs.h include\gc.h include\private\gcconfig.h MAKEFILE\r
\r
# not time-critical anyway.
# Set SPECIALCFLAGS to -q nodirect_code on Encore.
-all: base_lib gctest$(EXEEXT)
+all: base_lib
atomic_ops.o: $(AO_SRC_DIR)/src/atomic_ops.c
$(CC) $(CFLAGS) -c -o $@ $(AO_SRC_DIR)/src/atomic_ops.c
OBJS= misc.obj win32_threads.obj alloc.obj reclaim.obj allchblk.obj mach_dep.obj os_dep.obj mark_rts.obj headers.obj mark.obj obj_map.obj blacklst.obj finalize.obj new_hblk.obj dbg_mlc.obj fnlz_mlc.obj malloc.obj dyn_load.obj typd_mlc.obj ptr_chck.obj gc_cpp.obj gcj_mlc.obj mallocx.obj extra\msvc_dbg.obj thread_local_alloc.obj
-all: gctest.exe de.exe test_cpp.exe
+all: gc.lib
+
+check: gctest.exe test_cpp.exe de.exe
+ gctest.exe
+ test_cpp.exe
.c.obj:
$(cc) $(cdebug) $(cflags) $(CFLAGS_SPECIFIC) -Iinclude -I$(AO_INCLUDE_DIR) $(CFLAGS_DEFAULT) -DCORD_NOT_DLL -D_CRT_SECURE_NO_DEPRECATE $*.c /Fo$*.obj /wd4100 /wd4127 /wd4701
# Setjmp_test may yield overly optimistic results when compiled
# without optimization.
-all: $(OBJS) gctest.exe cordtest.exe
+all: gc.lib
+
+check: gctest.exe cordtest.exe
+ gctest.exe
+ cordtest.exe
$(OBJS) test.obj: include\private\gc_priv.h include\private\gc_hdrs.h include\gc.h include\private\gcconfig.h
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 test".
+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.
by a core dump or a message to the effect that the collector is broken. Gctest
takes about a second to two to run on reasonable 2007 vintage desktops. It may
use up to about 30 MB of memory. (The multi-threaded version will use more.
-64-bit versions may use more.) `make test` will also, as its last step, attempt
-to build and test the "cord" string library.)
+64-bit versions may use more.) `make check` will also, as its last step,
+attempt to build and test the "cord" string library.)
Makefile.direct will generate a library gc.a which you should link against.
Typing "make cords" will add the cord library to gc.a.
#------------------LINKING----------------------------
-all: gctest setjmp_t cordtest
+all: gc.lib cord.lib
clean:
delete *.lib gctest setjmp_t *.o *.lnk cord/*.o cord/tests/*.o cordtest
smake
-test: setjmp_t gctest cordtest
+check: setjmp_t gctest cordtest
setjmp_t
gctest
cordtest
dbg_mlc.obj malloc.obj dyn_load.obj &
typd_mlc.obj ptr_chck.obj mallocx.obj fnlz_mlc.obj gcj_mlc.obj
-all: gc.lib gctest.exe test_cpp.exe
+all: gc.lib
+
+check: gctest.exe test_cpp.exe .SYMBOLIC
+ *gctest.exe
+ *test_cpp.exe
!ifdef MAKE_AS_DLL
typd_mlc.obj\\r
win32_threads.obj\r
\r
-targets: gc.dll gc.lib gctest.exe test_cpp.exe\r
+targets: gc.dll gc.lib\r
+\r
+check: gctest.exe test_cpp.exe\r
+ gctest.exe\r
+ test_cpp.exe\r
+\r
+gc.lib: gc.dll\r
\r
gc.dll: $(OBJS) gc.def digimars.mak\r
$(CC) -ogc.dll $(OBJS) -L$(LFLAGS) gc.def kernel32.lib user32.lib\r
cd .libs
./lt-gctest
-Do not try to do "make test" (the usual way of running the test
+Do not try to do "make check" (the usual way of running the test
program). This does not work and seems to erase some of the important
files.
platform, library type (dynamic or static), calling conventions, and
optimization options.
-To compile the collector and testing programs use the command:
+To compile the collector use the command:
wmake -f WCC_MAKEFILE
All programs using gc should be compiled with 4-byte alignment.
NT_MAKEFILE has been used in this environment. Type
"nmake -f NT_MAKEFILE cpu=AMD64 nodebug=1" in a Visual C++ command line
window to build the release variant of the dynamic library with threads
-support and the usual test programs.
-To verify that the collector is at least somewhat functional, run gctest.exe.
-This should create gctest.gc.log after a few seconds.
+support.
+To verify that the collector is at least somewhat functional,
+type "nmake -f NT_MAKEFILE cpu=AMD64 check" to build and run the usual test
+programs. This should create gctest.gc.log after a few seconds.
Test_cpp.exe might not run correctly in case of dynamic GC linking. (It seems
that we're getting wrong instances of operator new/delete in some cases.)