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

[Richard Haney]

Here is another error, this time dealing with archiving, along with
some additional, important, but non-critical issues.

In response to "Assertion failed: e.op(1).is_equal(_ex2), file
indexed.cpp, line 701",

Chris Dams wrote:

> I would say that you can quite safely just delete this assertion.

Thanks for the post.

I commented out the assertion at line 701 in indexed.cpp and rebuilt
the library and ran "make checks".

Here are the relevant parts of the relevant output files:

output from the "make check-TESTS" part of "make check" output:
<begin quote>
[...]
examining miscellaneous other things........ passed 
Error: something went wrong. (one failure)
please check exams.out against exams.ref for more details.
happy debugging!
./exams.ref exams.out differ: char 707, line 30
FAIL: run_exams
[...]
======================================
1 of 3 tests failed
Please report to <ginac-list at ginac.de>
======================================
<end quote>

relevant part of "exams.out" (from line 29 to end):
<begin quote>
----------archiving system:
archiving/unarchiving
42*y^sin(Catalan*y)*ONE*eps.(1/2*y).0.(FAIL)*x+(2.4275000000000002132)*eps~y~*0+(gamma~mu*gamma.mu)*x.(1+2*y)~(-mu)*(I*f.x.y.2+d.x.y.2)*T.x+delta.(delta.x.($7)*[[-1,0,0],[0,Euler,0],[0,0,atan(y^(-1)*x==-15/17*I)]])~(ONE*{x,-11*y,(acos(6-10*I))+(-(26/3725-48/3725*I)*sqrt(65+120*I))*(-3+5*I+x)+((17364/13875625-652/13875625*I)*sqrt(65+120*I))*(-3+5*I+x)^2+Order((-3+5*I+x)^3)}*g~2~(log(cos((128.0)*y^(-1)*x^(-1)))))+((abs(y))+(D[0](abs)(y))*(-y+x)+(1/2*D[0,0](abs)(y))*(-y+x)^2+(1/6*D[0,0,0](abs)(y))*(-y+x)^3+Order((-y+x)^4))
erroneously returned 42*y^sin(Catalan*y)*ONE*eps.(1/2*y).0.(FAIL)*x
----------structure template:
(no output)
----------hash maps:
(no output)
----------miscellaneous other things:
(no output)
<end quote>

Could it be that the failure here is due to GiNaC's use of CLN's io
functions and specifically is a result of a bug indicated in CLN's
"test_I_io" failure as described in my previous post "[GiNaC-list]
Results of GiNaC (& CLN) builds" at
http://www.ginac.de/pipermail/ginac-list/2006-July/000857.html ?

Additional issues:

1. Note that "cd .libs && rm -f libginac.la && ln -s ../libginac.la
libginac.la" does not result in a new link file when rebuilding the
library.  (Output: "ln: `libginac.la': File exists".)  I had to
manually delete the link file (using Windows Explorer), whose full name
is "libginac.la.lnk" and which seems to be the same thing as a "Windows
shortcut".  Only execution of "dir lib*" in Windows' "command prompt"
shell reveals the complete name; "ls lib*" in cygwin bash only reveals
the name "libginac.la" with an arrow ("->") to the referenced file. 
Nor does Windows Explorer reveal the full name even though I have
"display filename extensions" turned on.  (This comment applies
similarly to the symbolic link "libcln.la.lnk" in the CLN build.)

2. The Makefile for building libginac.a does not seem to have the
correct dependency information for the dependency of libginac.a on
"indexed.cpp".  I had to resort to manually deleting all known
occurrences of "indexed.o", "indexed.lo", "indexed.Plo", "libginac.a",
"libginac.la", "libginac.la.lnk", and "libginac.lai" in order to get
the new version of indexed.cpp implemented in "libginac.a". 
(Conceivably, this may have something to do with "rm -f libginac.la"
not being effective, as described in note 1 above.  On a seemingly
related note, it also seems that the Makefiles are confused about
whether executables have an .exe extention.  For example, the "clean"
target in the "cln-1.1.11\tests" Makefile has command a line "$(RM) *.s
*.o *.a exam tests main a.out core"; however, the Makefile in
"ginac-1.3.4\ginsh" _does_ seem to account for the .exe extension in
target "clean-binPROGRAMS".  It has often seemed though that
executables get automatically remade (in CLN and/or GiNaC) even though
nothing has changed when rerunning make.  I surmise that this may be
due to incorrect specification of dependencies as to the .exe
extensions.

3. There is some doubt in my mind whether symbolic links in cygwin bash
work properly.  I seem to recall trying to use a symbolic link a few
years ago and found that I had to resort to simply copying the target
file to replace the link.  But I have not played with symbolic links in
"standard" unix, so I don't know whether I was simply trying to use
them incorrectly.

4.  Now that a satisfactory build of libginac.a seems to be within
view, I'd like to get a "shared" (.dll) version of both "libcln.a" and
"libginac.a", but even though I think I am following directions for
getting shared libraries, I don't seem to be getting them.  A typical
make output (for both CLN and GiNaC) that may have something to do with
this is "libtool: link: warning: undefined symbols not allowed in
i686-pc-cygwin shared libraries".  Note that "cygwin" is only relevant
by virtue of my using cygwin bash (& cygwin "sed", "ln", "mkdir', "rm",
and perhaps some other minor tools that have escaped my attention). 
All of my essential build tools (except sed, etc.) -- i.e., gcc 3.4.2
and associated tools and runtime libraries -- are "mingw" tools or what
is supplied with the CLN/GiNaC packages.  The "mingw" tools bin appears
earlier in PATH than does the cygwin bin.  I surmise that, except where
I specify otherwise more specifically, all of the runtime library paths
are determined by gcc (or g++) relative to the location of the gcc/g++
bin.

As before, the relevant system specs are:

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

Richard Haney

P.S.:  Thanks to Sheplyakov Alexei for his posts.  I have looked at
them and will look at them some more, but they are not in a form that I
can readily make use of.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com