- GiNaC-list - ginac.de

CXXABI_1.3.1
by Marko Riedel 07 Sep '06

07 Sep '06

Hi folks, I downloaded, compiled and installed GiNaC using the following version of gcc: gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure Thread model: posix gcc version 4.0.2 I now appear to have a working setup. E.g. I can run "ginsh": ginsh - GiNaC Interactive Shell (ginac V1.3.5) __, _______ Copyright (C) 1999-2006 Johannes Gutenberg University Mainz, (__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY. ._) i N a C | You are welcome to redistribute it under certain conditions. <-------------' For details type `warranty;'. When I compile and run my test program, however, I get the following error message: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.1' not found \ (required by /usr/local/lib/libginac-1.3.so.2) Am I perhaps missing some environment variables or compiler switches here? I have the following files: /usr/include/c++/3.3/cxxabi.h /usr/local/include/c++/4.0.2/i686-pc-linux-gnu/bits/cxxabi_tweaks.h /usr/local/include/c++/4.0.2/cxxabi.h I compiled my program with the following command: c++ -g complete41.cpp -o complete41 -I/usr/local/include -lcln -lginac Any help would be appreciated. Best regards, Marko Riedel -- +------------------------------------------------------------+ | Marko Riedel, EDV Neue Arbeit gGmbH, mriedel(a)neuearbeit.de | | http://www.geocities.com/markoriedelde/index.html | +------------------------------------------------------------+

2 2

compiling cln 1.1.13
by Marko Riedel 07 Sep '06

07 Sep '06

Hi folks, I am trying to compile cln on Debian 3.1 (Kernel 2.6.12). This is my version of gcc: gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure Thread model: posix gcc version 4.0.2 This is the output from "make". I get the impression that I have to set an environment variable to specify endianess. cd src && make all make[1]: Entering directory `/usr/local/src/cln-1.1.13/src' make SUBDIR=base make[2]: Entering directory `/usr/local/src/cln-1.1.13/src' /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include \ -I./base -c ./base/cl_N_err_d0.cc mkdir .libs g++ -O -I../include -I../include -I./base -c ./base/cl_N_err_d0.cc \ -fPIC -DPIC -o .libs/cl_N_err_d0.o In file included from ./base/cl_N_err_d0.cc:4: ./base/cl_sysdep.h:30:4: error: #error "Bogus CL_CPU_BIG_ENDIAN_P!" In file included from ./base/cl_macros.h:6, from ./base/cl_sysdep.h:56, from ./base/cl_N_err_d0.cc:4: ../include/cln/types.h:18:6: error: #error "No 8 bit integer type?" ../include/cln/types.h:25:6: error: #error "No 16 bit integer type?" ../include/cln/types.h:35:6: error: #error "No 32 bit integer type?" ../include/cln/types.h:57: error: 'sint8' does not name a type ../include/cln/types.h:58: error: 'uint8' does not name a type ../include/cln/types.h:60: error: 'sint16' does not name a type ../include/cln/types.h:61: error: 'uint16' does not name a type ../include/cln/types.h:63: error: 'sint32' does not name a type ../include/cln/types.h:64: error: 'uint32' does not name a type ../include/cln/types.h:128: error: 'sint32' does not name a type ../include/cln/types.h:129: error: 'uint32' does not name a type ../include/cln/number.h:194: error: expected constructor, destructor, \ or type conversion before 'CL_DEFINE_LONG_ASSIGNMENT_OPERATORS' make[2]: *** [cl_N_err_d0.lo] Error 1 make[2]: Leaving directory `/usr/local/src/cln-1.1.13/src' make[1]: *** [base.target] Error 2 make[1]: Leaving directory `/usr/local/src/cln-1.1.13/src' make: *** [all] Error 2 Can you help me out here? Thanks! -- +------------------------------------------------------------+ | Marko Riedel, EDV Neue Arbeit gGmbH, mriedel(a)neuearbeit.de | | http://www.geocities.com/markoriedelde/index.html | +------------------------------------------------------------+

2 2

libstdc++5 vs 6
by Marko Riedel 06 Sep '06

06 Sep '06

Hi folks, I installed the GiNaC Debian package on my machine. I now have ||/ Name Version Description +++-==============-==========-============== ii libginac-dev 1.3.0-2 The GiNaC framework (development files) I get the following warning when I link my test program: /usr/bin/ld: warning: libstdc++.so.5, \ needed by /usr/bin/../lib/libginac.so, \ may conflict with libstdc++.so.6 The program segfaults in GiNaC::matrix::operator= (). How do I tell the linker to link against libstdc++.so.5 only, thereby avoiding conflicts? This is my version of GCC: gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure Thread model: posix gcc version 4.0.2 Thanks! -- +------------------------------------------------------------+ | Marko Riedel, EDV Neue Arbeit gGmbH, mriedel(a)neuearbeit.de | | http://www.geocities.com/markoriedelde/index.html | +------------------------------------------------------------+

2 1

doxygen, TeX, latex, and pdflatex
by Richard Haney 21 Aug '06

21 Aug '06

It's nice that the INSTALL document now gives at least _some_ "warning" about extra software that will be needed for the build, namely: "To build the GiNaC tutorial and reference manual the doxygen utility (it can be downloaded from http://www.stack.nl/~dimitri/doxygen ) and TeX are necessary." But that is all the documentation says about these packages. But it also seems that this information, besides being rather scant, may also be a bit misleading. A case-insensitive "grep" of "C:/gnu/ginac-1.3.5" reveals no occurrence of "tex" except as a part of "text" or as a part of variable names such as CONFIG_TEX_TRUE, LATEX, and PDFLATEX. A search through the configure output and the config.log output of ginac-1.3.4 suggests that configure does not look for any TeX executable or library as such, but instead looks for doxygen, latex, and pdflatex, but no details are given there as to what configure specifically is looking for. Then a search for these keywords in the ginac-1.3.5 configure script seems to confirm that these packages (as executables with presumably several different extensions attempted) are typically searched for in the PATH variable (which presumably is the environment variable by that name) and that the lines ac_cv_path_DOXYGEN="$DOXYGEN" # Let the user override the test with a path. ac_cv_path_LATEX="$LATEX" # Let the user override the test with a path. ac_cv_path_PDFLATEX="$PDFLATEX" # Let the user override the test with a path. allow the user to specify the pathnames for these three executables by setting environment variables or using command line arguments, rather than having to have the executables "installed" in a PATH directory. (If true, that's nice to know, but I don't recall seeing anything to this effect even in the "./configure --help" output.) To my knowledge, LaTex is a control ("macro" ?) package for TeX -- actually a substantial family of packages, one of which needs to be chosen, but conceivably it could be also have now evolved (with name in lower case) into a "stand-alone" executable, which is what the configure script seems to be looking for. Moreover, I could find no suggestion either in the ginac-1.3.5 configure script or in the ginac-1.3.4 output (including config.log) that configure looks for anything with a root name of "tex". I have no idea what pdflatex is except that it seems likely by its name to be some extension of the LaTeX concept for use in creating .pdf files. But all of this is a lot of guessing based on what I found. Also, even though the .info documentation says "Perl is needed by the built process as well, since some of the source files are automatically generated by Perl scripts.", a case-insensitive grep of "C:/gnu/ginac-1.3.5" reveals that "perl" appears only in a few comment lines and thus seems to be irrelevant to "ginac-1.3.5". Can someone provide some clarification as to what is needed here? I also recall that TeX packages are quite varied and can be quite huge and thus likely to be much more than is needed here. Can anyone suggest an appropriate TeX package if that is what's needed? Similar considerations apply for LaTeX as well, if that is what's needed. I am interested in building the html and pdf documentation for GiNaC. Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

Release of GiNaC 1.3.5
by Jens Vollinga 18 Aug '06

18 Aug '06

Hi everybody, GiNaC 1.3.5 is out and available. The changes are: - Re-built bison related files that caused bugs with gcc 4. - Fixed bugs in fderivative::match_same_type(), expairseq::match(), expand_dummy_sum(), and expairseq::map(). - Fixed template specialization for class container to be gcc 4.2 compliant. - Output in csrc mode is now -x instead of -1.0*x. - Fixed tutorial and reference generation in html/pdf/ps format. - Modified autotool configuration to allow for compilation on MinGW. - Debian packaging files updated. As always, this release can be downloaded from http://www.ginac.de/Download.html Best wishes, Jens

1 0

Possible size issue in test in numeric.cpp
by Pierangelo Masarati 17 Aug '06

17 Aug '06

Hi. We're using GiNaC inside our multibody analysis software MBDyn to perform automatic differentiation of constitutive laws for deofrmable elements. Right now its use is not very intensive, but we plan to extend it quite soon. I haven't built GiNaC for a while, and today, rebuilding a 1.3.4 rpm, I noticed a warning in numeric.cpp. First, a note on the system: it's an AMD Athlon 64, running CentOS 4.2, which means stock RedHat gcc/g++ 3.4.5. I haven't checked with gcc 4.X yet, but the issue seems to be clear enough. The warning is at line 95 of ginac/numeric.cpp and it didn't change from GiNaC 1.3.4 to today's CVS: [masarati@ando ginac]$ make numeric.o if g++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -MT numeric.o -MD -MP -MF ".deps/numeric.Tpo" -c -o numeric.o numeric.cpp; \ then mv -f ".deps/numeric.Tpo" ".deps/numeric.Po"; else rm -f ".deps/numeric.Tpo"; exit 1; fi numeric.cpp: In constructor `GiNaC::numeric::numeric(int)': numeric.cpp:95: warning: comparison is always true due to limited range of data type numeric.cpp:95: warning: comparison is always true due to limited range of data type The constructor of "numeric" that takes an "int" as its argument "i" performs the test i < (1L << (cl_value_len-1)) On my system, "cl_value_len" is 32; so, "1L << 31" is out of range for an "int". Then, the test i >= -(1L << (cl_value_len-1)) follows, which is again out of range for an int. It took a while to figure out what that code was intended for. It appears that cln uses few bits of an int, on 32 bit architectures, to store reserved metainformation; on the contrary, on architectures with 64 bit pointers, the whole int range is available. My guess is that the test is incorrect on those architectures, but I admit I haven't investigated enough. I've placed a patch at <http://mbdyn.aero.polimi.it/~masarati/Download/mbdyn/ginac-numeric.patch>, please review or feel free to fix as appropriate, in case I'm missing anything obvious. Sincerely, p. Dr. Pierangelo Masarati | voice: +39 02 2399 8309 Dip. Ing. Aerospaziale | fax: +39 02 2399 8334 Politecnico di Milano | mailto:pierangelo.masarati@polimi.it via La Masa 34, 20156 Milano, Italy | http://www.aero.polimi.it/~masarati Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

4 12

Result of building cln-1.1.13 on pc (Windows XP) with cygwin
by Richard Haney 13 Aug '06

13 Aug '06

I have posted a message on the cln list regarding results of building cln-1.1.13 on pc (Windows XP) with cygwin. There are several notable facts about the build, as described in that message. The message may be found at http://www.cebix.net/pipermail/cln-list/2006-August/000212.html Best regards, Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

"make html" and "make pdf" don't work?
by Warren Weckesser 12 Aug '06

12 Aug '06

Hello again, Chris, thanks for the fast response to my previous post. That kind of responsiveness can only lead to one thing: more bug reports and requests! Here's one. According to the tutorial (Section 3.3 Building GiNaC), I can build the documentation with "make" commands such as $ make html $ make pdf Here is what I get when I try this (using ginac version 1.3.4). I am running the "make" commands in the same directory where I just completed the usual "./configure" (with no options) and "make" commands. First I tried "make html": -------------------------------------------------------------------- $ make html make: *** No rule to make target `html'. Stop. -------------------------------------------------------------------- Next, "make pdf": -------------------------------------------------------------------- $ make pdf ... snip (lots of latex stuff) ... Output written on ginac.pdf (118 pages, 753760 bytes). Transcript written on ginac.log. make[2]: Leaving directory `/home/wweckesser/test_ginac_doc/ginac-1.3.4/doc/tutorial' Making pdf in reference make[2]: Entering directory `/home/wweckesser/test_ginac_doc/ginac-1.3.4/doc/reference' warning: target reference.pdf disabled by configuration This is pdfeTeX, Version 3.14159-1.10b-2.1 (Web2C 7.4.5) entering extended mode ! I can't find file `reference.tex'. <*> reference.tex Please type another input file name: --------------------------------------------------------------------- "make pdf" successfully builds the file ginac.pdf in doc/tutorial, but something goes wrong in doc/reference. Best regards, Warren

2 2

Re: [GiNaC-list] Python wrapper for a GiNaC derived library
by Vladimir Kisil 10 Aug '06

10 Aug '06

Ondrej Certik ondrej at certik.cz write on Thu Jul 20 00:13:29 CEST 2006 > We also created swiginac (http://swiginac.berlios.de/) for those, who > are interested in using ginac from python. > just my opinion: boost-python took ages to compile on my machine and > the errors were completely unreadable. swig compiles much faster, and > also it seems easier to learn. Do others have similar experience, or > totally different? I agree that both BoostPython and pyGiNaC have some issues and may be willing to make my library wrap in swiginac as well. However the swiginac is not supporting the new tinfo system and I cannot see right now how to patch it. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

6 18

"Internal error..." report -- probably misused map.
by Warren Weckesser 10 Aug '06

10 Aug '06

Hi, I am working on a program that generates code for other libraries or programs. One of the target libraries is CVODE, a solver for differential equations (part of the SUNDIALS suite). In CVODE, numbers are represented with a typedef 'realtype', which can be chosen to be float, double, or one or two other options. To ensure consistent use of realtype, constants are wrapped in the macro RCONST. I am trying to automate this in ginac. I am using ginac version 1.3.4 (compiled with gcc 4.0.2 on Ubuntu Linux). In some of my first attempts to do this, I occasionally got an "internal error" message. The following code is a simplified version that causes the error: --- ginacwrap1.cpp -------------------------------------------- #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; DECLARE_FUNCTION_1P(RCONST) REGISTER_FUNCTION(RCONST,dummy()) ex wrap1(const ex & e) { if (is_a<numeric>(e)) return RCONST(e); else return e.map(wrap1); } int main(void) { symbol x("x"); ex p = cos(1+x); // Internal error: ... line 93 has been reached! // ex p = 2*x; // Internal error: ... line 30 has been reached! // ex p = 2+sin(2); // Works: wrap1(p) = RCONST(2)+sin(RCONST(2)) ex w = wrap1(p); cout << "wrap1(p) = " << w << endl; } --------------------------------------------------------------- This results in an "internal error": Internal error: statement in file ./real/elem/cl_R_mul.cc, line 93 has been reached!! Please send the authors of the program a description how you produced this error! If the expression p is changed to 2*x (see the comments), a similar internal error is reported. After more work, I ended up with the code shown below, which seems to do what I want (but any suggestions for a better method would be appreciated). I had to define my own print function for the RCONST function, because the default print function converted the name to lower case when csrc was used. One remaining nuisance: In csrc mode, ginac prints the expression -x as "-1.0*x". Is there a way to have it output "-x" in csrc mode? Best regards, Warren Weckesser --- ginacwrap2.cpp -------------------------------------------- #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; static void RCONST_print_csrc_double(const ex & arg, const print_context & c) { c.s << "RCONST("; arg.print(c); c.s << ")"; } DECLARE_FUNCTION_1P(RCONST) REGISTER_FUNCTION(RCONST,print_func<print_csrc_double>(RCONST_print_csrc_double)) ex wrap2(const ex& e) { if (is_a<numeric>(e)) return RCONST(e); if (is_a<symbol>(e)) return e; if (is_a<add>(e)) { ex s = 0; for (size_t k = 0; k < e.nops(); ++k) s = s + wrap2(e.op(k)); return s; } if (is_a<mul>(e)) { ex p = 1; for (size_t k = 0; k < e.nops(); ++k) p = p * wrap2(e.op(k)); return p; } return e.map(wrap2); } int main(void) { symbol x("x"); cout << csrc; ex p = -exp(-x)+x*x; cout << "p = " << p << endl; ex w = wrap2(p); cout << "wrap2(p) = " << w << endl; } ----------------------------------------------------------------

2 2