Appended to this message is the result of building and testing GiNaC with "make check-TESTS". In summary, all three of the "runs" (run_exams, run_checks, run_times) failed although some of the subtests passed. Also appended are listings of the "exams.out", "checks.out", and "times.out" files. Here are some relevant system specs: OS: Windows XP gcc: gcc version 3.4.2 (mingw-special) ld: GNU ld version 2.15.91 20040904 installer package (for mingw tools): devcpp-4.9.9.2_setup.exe gdb: version 5.2.1 (from gdb-5.2.1-1.exe ) _mingw.h: #define __MINGW32_VERSION 3.7 w32api.h: #define __W32API_VERSION 3.2 bash (for environment variables & executing configure & make commands): GNU bash, version 2.05b.0(8)-release (i686-pc-cygwin) CLN: version 1.1.11 GiNaC: version 1.3.4 Hopefully, with my description of the problems someone can provide information on how to resolve them and perhaps clear up some other dubious points that this description suggests. Hopefully, the problems are even very simple to correct. I decided to build the readline library although I suppose I may have been able to use "cygreadline5.dll"; in fact a test (after I had partially built the readline library) suggested that this is likely so; I surmise that essential .dll linkage specifications tend to be more stable and universal (and compiler-independent) than are static library linkage specifications. (The static cygwin libraries were most likely built with an "ancient" gcc and I surmised that they probably would not be compatible with a more recent gcc's output -- I think I've tried linking to some of them before.) I also built the termcap library to use with the examples in the readline library build. First, I briefly describe the problems with CLN: In building CLN I had to do considerable finagling with the Makefiles. (Typically, as from earlier experience in building an earlier version of CLN and GiNaC, I had to temporarily comment out the mingw's make.exe so that Borland's make.exe (the next make.exe in PATH) would answer configure's question "checking whether make sets $(MAKE)" with the right answer: yes; the test with mingw's make.exe says "no", but "yes" seems to be the appropriate answer for mingw's make.exe. Also, I had to change "/cygdrive/c" to "C:" (and sometimes also "/usr/bin" to "C:/cygwin/bin") in the Makefile pathnames for build tools and libraries and add "--tag=CXX" to libtool lines, especially if I wanted to execute make in a subdirectory.) And I ran into one error with "make check" at "test_I_io", resulting in the output "Illegal number syntax" evidently from function read_number_bad_syntax() in "cl_read_err_bad.cc". But when I commented out that test for "test_I_io" in function test_I(), the "make check" run was otherwise fine. I also set up a run of only the "test_I_io" test and found that the error occurred when I compiled the tests modules with -O2 optimization, but the error did not occur when I compiled them with the no (i.e., -O0) optimization. I also tried to use gdb with tests.exe but found that I could not set breakpoints in cl_I_read.cc, cl_I_read_stream.cc, or cl_read_err_bad.cc even though I recompiled these modules with the "-g -O0" flags and then rebuilt "libcln.a" using these three rebuilt object modules. (I even tried removing these three modules from the library build and putting them in the "tests" directory, but I seem to have run into "order-of-initialization" problems as suggested in header file "cln/modules.h"; the linker error in this case was "C:/Dev-Cpp/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined reference to `WinMain@16'".) I also made sure the -s linker flag did not appear in the commands in building "libcln.a" as well as "tests.exe". (However, I surmise that libtool may be doing some rather mysterious things in getting "database" information from mysterious files; but in each case -s did not appear in the immediately subsequent g++ command line that I surmise is generated by libtool and that seemingly should be regarded as the unequivocal description of what g++ is doing to build "libcln.a".) I also set up a rebuild of tests.exe and used "drmingw tests.exe" and an intended exception/fault in "cl_read_err_bad.cc", but the stack traceback output I got seemed slightly erratic. (If I recall correctly, I think there was listed an extraneous call to cl_abort() before the call to read_number_bad_syntax().). I surmised later that the erratic output was probably due to the fact that most of the relevant object modules for tests.exe were built with -O2. I also set up a run to force linkage of tests.exe to link to the mpatrol library to see if the error could be due to heap-memory or C-memory-function errors, but even though I got a rather large, verbose, three-figure MB log file, that log file showed no memory errors. Unfortunately, read_number_bad_syntax() calls something like cl_abort() rather than returning control to the calling function with an error indication. As a result an after-failure call to an "outside hook" function cannot easily be made for setting breakpoints and examining variables with gdb -- note that gdb breakpoints _can_ be set in functions whose object modules are not a part of the CLN library. (But rebuilding the library after its input object modules have been built is rather time-consuming as well, discouraging experimentation.) So with the dependency of the test on using optimization (or not) in compiling and linking the "tests" modules, I figured the problem was probably connected with the "order-of-module-initialization" issues described in header file "cln/modules.h" (which issues are apparently dependent on optimization); and so I decided to proceed with building the readline libraries and GiNaC, and possibly come back to this issue with "test_I_io" later, depending on how successful I was with GiNaC. Problems with GiNaC: Because of earlier experience, I generally made modifications to all of GiNaC's Makefiles in accordance with the ideas discussed above for CLN. I also liberally listed library names (sometimes pathnames) for the various "LIBS" and "..._LIBS" variables (even though many of these variables are not used), and I included "-lstdc++ -lmingw32" for these variables because an earlier build of GiNaC suggested that they were needed. I figured that duplication of library names on command lines probably wouldn't hurt and the Makefiles could be more easily adjusted if necessary, if duplication problems did arise. And I decided I needed to copy "libreadline.5.dll" (and "libhistory.5.dll" even if not needed) to "C:\Dev-Cpp\bin", the binary folder for my mingw gcc 3.4.2 and other mingw tools. This "bin" is in my PATH variable used to search for executables. I also had to make several adjustments of to config.h to account for the fact that I actually did have a readline library even though configure said I didn't -- three macro variables should say I have readline and two should provide the version numbers. (I copied "libreadline.5.dll" to "C:\Dev-Cpp\bin" after I ran GiNaC's configure.) I also had to modify "ginsh_parser.cc" (in folder "ginsh") and "timer.h" and "timer.cpp" (in folder "check") to use header <ctime> and function clock() in place of header <sys/resource.h> and function getrusage(), which apparently are not in my mingw runtime libraries. I also commented out (with //) all the "#line" (presumably comment) lines in ginsh_parser.cc because a comment in an earlier version of GiNaC said some compilers may choke on them -- I was trying to make the setup as robust as possible. (By the way, ginsh.exe seems to be working as intended.) So after a horrendous amount of finagling and discovery of what works and what doesn't, I finally completed the "make check-TESTS" test for GiNaC. Since the problems don't seem to be obviously trivial, even if minor adjustments could fix them, I have decided to see if I can get some help on this. I could send a zip file of my most recently modified Makefiles (particularly the .rtf backup versions that have manual modifications highlighted in boldface) and modified .cc, .cpp, and .h files if anyone is interested. (I usually create the text-format Makefiles from the .rtf backup versions). I also use the "modified" time-stamps in backups with descriptive file names and output files to keep a chronological history of what I've tried. And I often use "touch -m --reference=..." to synchronize text versions with .rtf backup versions, which are easier to edit with WordPad. (A newly created "Makefile" from an .rtf backup is what I usually use as the reference in the touch command to synchronize the Makefile with its backup. And I often add date/time stamps in the file names for easy overviews in Windows Explorer with files sorted as to modified date/time. The date/time stamps in the file names also serve to keep the output file names distinct in a sequence of experimentally varied trial runs.) Richard Haney Here are the appended listings of files: make_check-TESTS_out.rtf: GiNaC will now take an exam with specific input (like a pupils' exam): examining several historic failures just out of paranoia........./exams.ref exams.out differ: char 39, line 2 FAIL: run_exams GiNaC will now run through some rather costly random consistency checks: checking consistency of numeric types.. passed checking consistency of symbolic functions.... passed checking symbolic matrix manipulations./checks.ref checks.out differ: char 153, line 6 FAIL: run_checks GiNaC will now run through some basic timings: timing commutative expansion and substitution.... passed size: 50 100 200 400 time/s: 0.19 0.719 3.109 13.8 timing Laurent series expansion of Gamma function.... passed order: 10 15 20 25 time/s: 0.16 0.51 2.49 9.349 timing determinant of univariate symbolic Vandermonde matrices./times.ref times.out differ: char 192, line 6 FAIL: run_times ====================================== 3 of 3 tests failed Please report to <ginac-list@ginac.de> ====================================== c:\Dev-Cpp\bin\make.exe: *** [check-TESTS] Error 1 exams.out: ----------several historic failures: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. checks.out: ---------consistency of numeric types: (no output) ---------consistency of symbolic functions: (no output) ---------symbolic matrix manipulations: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. times.out: -------commutative expansion and substitution: (no output) -------Laurent series expansion of Gamma function: (no output) -------determinant of univariate symbolic Vandermonde matrices: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ==== end of message ==== __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com