[GiNaC-list] Results of GiNaC (& CLN) builds

[Richard Haney]

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 at 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 at 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