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