August 2006 - GiNaC-list

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

GiNaC is not a package manager (Was.. ...
by Richard Haney 08 Aug '06

08 Aug '06

Alexei, --- "Sheplyakov Alexei" <varg(a)theor.jinr.ru> wrote: > On Sun, Aug 06, 2006 at 04:20:11PM -0700, Richard Haney wrote: >> It seems to me that an extremely good idea is to make a general >> practice of keeping separate software packages in separate file >> hierarchies, > >This is in fact very bad idea... I was hoping to stimulate a discussion of the pros and cons. Could you give some reasons? I suppose there are probably both good and bad reasons for the idea, and it seems that knowing the various reasons ahead of time could save having to deal with a lot of needless problems later. As packages are installed and built, a certain amount of commitment is built up over time, and thus, it can become costly to undo bad decisions. But it's not completely clear to me what all the potential problems might be one way or the other. I've indicated some considerations as to why I think the idea is a good one. >> and moreover it seems to be more complication for the user than >> should be necessary. > > You made this complication yourself (by choosing weird installation > paths). I was trying to suggest an approximate solution using _existing_ facilities in the GiNaC as distributed, as a lead-in to the next variation proposed, which seems a better, simpler approach, but would seem to require a modification of GiNaC distribution: >> It seems one possibility would be a command such as >> ./configure CLN="C:/gnu/cln-1.1.11/gcc342" >> READLINE="C:/gnu/readline-5.1/gcc342" >> TERMCAP="C:/gnu/termcap-1.3.1/gcc342" > >GiNaC configure script provides --with-cln-prefix option So it seems that perhaps this following command should work (without having to have the relevant libraries installed in a central, PATH-and/or-gcc-dependent repository): ./configure --with-cln-prefix="C:/gnu/cln-1.1.11/gcc342" CPPFLAGS="-IC:/gnu/readline-5.1/gcc342/include [-IC:/gnu/termcap-1.3.1/gcc342/include]" LDFLAGS="-LC:/gnu/readline-5.1/gcc342/lib [-LC:/gnu/termcap-1.3.1/gcc342/lib]" I've put the termcap references in brackets [] because it's not clear to me whether the bracketed parts are needed (in the next distributed version of GiNaC, at least). Would this work? It would probably take me at least a half day to test this. Does anyone see any problem with it? But note that there is some redundancy here in the command line. A preferred command line might be (omitting the termcap reference as well): ./configure --with-cln-prefix="C:/gnu/cln-1.1.11/gcc342" --with-readline-prefix="-IC:/gnu/readline-5.1/gcc342" This, of course, would require that the GiNaC distribution be modified accordingly and that the installation structure for readline be the standard one with the root directory the one specified. >> Another improvement that seems a good idea is in general to place a >> single value -- such as, for example, the configure script's option >> value of "--prefix" -- in one standard location that all Makefiles >> would refer to, > > You might want to read autoconf manual, specifically the chapter about > CONFIG_SITE variable. I was thinking in terms of simple changes to the GiNaC distribution so that a new user wouldn't have to read the autoconf manual. One possibility would be to have an include file -- say, in the root build directory (i.e., with "configure") -- that each of the Makefiles would include to function as a part of each such Makefile. >> I would like to hear what others think of the general idea and various >> practices in managing software packages to be as mutually independent >> as possible, except where dependence is really needed. > > Long time ago package managers was written to solve these problems. If > your OS lacks such a package manager, GiNaC is not going to provide one. Well, I suppose a package manager might be one approach or part of a more general approach, but I wasn't thinking that special package management software would be necessarily a part of such a general approach. A human operator needs to make allocation planning and priority decisions at least. So some degree of manual operation seems necessary. I would hope for an appropriate management scheme/philosophy and simplified procedures. Allowing for or providing some additional support for flexibility here -- according to what the user prefers -- seems perhaps a good idea. > think porting dpkg/APT to win32 would be better approach. I looked on the Internet and didn't find anything informative that I could examine to get an idea of what's involved in your suggestion. So at the moment porting dpkg/APT seems out of my reach as far as anything I could do. Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

some flexibility problems with configure
by Richard Haney 07 Aug '06

07 Aug '06

Since running the GiNaC's configure script typically takes a considerable amount of time, it seems that there is a need for more flexibility (as well as robustness and, of course, speed) in the build/install process, and it seems that it is particularly important that the INSTALL documentation should be especially clear on a number of things in this regard. A few years ago when I built CLN and GiNaC, I had a rather slow computer. It took me at least two weeks of several hours per day running my computer to do the builds. I also encountered a number of "real bugs" and "false bugs" (e.g., the -- as of at least now -- misleading problem with configure's "checking whether make sets ${MAKE}"). After running configure and then make for many days and then discovering that changing some files could clobber my Makefiles, I became especially concerned about the possibility that some of the extremely time-consuming builds of object files could be inadvertently destroyed because of evident, but unclear, "Rube Goldberg" mechanisms in Makefiles and the experimental adjustments I might try making. I eventually figured out that I needed to keep backup copies of every single version of Makefile modifications. And I finally figured out that I should run something like "make -k &> make_-k_out.txt" to preserve a record and to make the best progress without having to constantly check (over a period of several hours each day) whether the make process has crashed on some bug. (The output file "make_-k_out.txt" then gets its name changed manually to something like "make_-k_out--2006-08-05, 1..24 pm.txt" so it won't be clobbered by a re-use of the command line.) It seems some advice in this regard in the INSTALL file would be a good idea. Well, I now have a significantly faster computer and I suppose that there have also been some improvements in the intrinsic robustness, speed, and flexibility of GiNaC builds. But the earlier concerns of mine seem still to be present, especially for a new user of GiNaC and its build process. It needs to be made clear what things a person can modify without causing great havoc and having to start the build processes over from scratch. Hopefully, this could be done in a clear fashion without requiring a high degree of special expertise (say of autoconf, automake, configure, make, etc.) by the user. Some Makefiles, in particular, are extremely intricate and elaborate and seem to resemble "Rube Goldberg" contraptions. If the user discovers that something in the make process is not working as expected, it seems a good idea to allow him or her to make adjustments to Makefiles and/or perhaps other files without causing irreversible havoc. (This sort of thing has seemed absolutely necessary in my build of readline, including a very inelegant hack of the script "shlib-install" -- due to a "shift" command not skipping the argument "C:/cygwin/bin/install -c -m 644" (with quotes) as one entire unit -- in order for directory "C:/gnu/readline-5.1/gcc342/bin" to be created and the DLLs installed there as evidently intended. This kind of thing makes a newbie wonder what kind of horrendous debugging hoops he will have jump through in building something like GiNaC. Similar issues with bugs in CLN and GiNaC compiler source files have recently been addressed here by Sheplyakov Alexei and seemed to be still present this year after my three-and-a-half-year hiatus from CLN and GiNaC builds.) It seems to me that an extremely good idea is to make a general practice of keeping separate software packages in separate file hierarchies, especially when one is installing packages tentatively and may want to delete or uninstall such packages later. In other words, it seems an extremely good idea to keep packages as mutually independent as possible, and when dependence is necessary, to make it very clear (by adding strategically named annotation files, for example) what that dependence is. (An exception would be several standard packages that are designed by a single group -- e.g., MinGW -- for installation in a common hierarchy.) I recall once deleting and/or uninstalling my cygwin hierarchy "C:\cygwin" and then later deciding that I wanted to re-install it. Any important files added to the hierarchy before deleting it would likely be lost without special care to search the hierarchy's directories for past adjustments and additions. (For example, I have changed the name of "bunzip2.exe" to "bunzip2.exe--DANGEROUS_DEFAULTS.exe" in "C:\cygwin\bin" and supplied a script file "bunzip2" to execute "bunzip2.exe--DANGEROUS_DEFAULTS.exe" using safer default options.) And if any files get installed in the typical default "/usr/local", those files would be a part of the "C:\cygwin" hierarchy (if using cygwin bash) and thus would risk being lost should cygwin be uninstalled (and/or updated). So for these reasons I have preferred to keep software packages and their "installations" in their own hierarchies. (So for example my preferred root installation directory for GiNaC is "C:\gnu\ginac-1.3.4\gcc342" -- that's "/cygdrive/c/gnu/ginac-1.3.4/gcc342" or "C:/gnu/ginac-1.3.4/gcc342" in a cygwin bash context, especially where "\" has a special meaning.) A major motivation is the desire to initially install packages only tentatively. I want to be careful about loading my disk unnecessarily with large numbers of packages that consume vast amounts of disk space. (For example, I have resisted installing the Microsoft's "free" C++ Visual Studio Express because the -- presumably much compressed -- installer consumes about 135 MB of storage and I am concerned the actual installation could consume, say, a gigabyte of storage.) I recently installed Dev-C++ because of comments I found on "Wikipedia" comparing IDEs and especially because I wanted to have a "safe" installation of the highly portable wxWidgets and because the Dev-C++ package incorporates all the essentials of MinGW gcc 3.4.2, the latest stable version of gcc (at the time). So now with my build of CLN and GiNaC I have somewhat compromised my general plan of package-installation independence and placed copies of various libraries -- for example, "libtermcap.a", "libreadline.a", "libhistory.a", "libgw32c.a", and now "libcln.a" and "libginac.a" -- in my "C:\Dev-Cpp\lib" directory and various DLLs and "cln-config" in "C:\Dev-Cpp\bin". ("Filename" annotations added to these directories include, for example, empty files "cln-config--from 'C.._gnu_cln-1.1.11_gcc342_bin'.txt", "libreadline.5.dll from readline-5.1 build--see 'C.._gnu'.txt", and "libginac.a from 'C.._gnu_ginac-1.3.4_gcc342_lib'.txt". When a directory is displayed in alphabetical order, such an annotation file appears next to the associated "installed" file for quick reminder of the "installed" file's origin.) One possibility that may perhaps work when building GiNaC for example is to use the rather long command ./configure CPPFLAGS="-IC:/gnu/cln-1.1.11/gcc342/include -IC:/gnu/readline-5.1/gcc342/include -IC:/gnu/termcap-1.3.1/gcc342/include" LDFLAGS="-LC:/gnu/cln-1.1.11/gcc342/lib -LC:/gnu/readline-5.1/gcc342/lib -LC:/gnu/termcap-1.3.1/gcc342/lib" but this does not satisfy GiNaC configure's need to find "cln-config" (in "C:/gnu/cln-1.1.11/gcc342/bin") and moreover it seems to be more complication for the user than should be necessary. It is not clear to me whether this would work for GiNaC builds with appropriate prepackaging adjustments vis-a-vis GiNaC configure's current need to find "cln-config" -- even if cygwin bash would allow arbitrarily long command lines. But it seems that some relatively simple adjustment to GiNaC's packaging could allow for such simple, flexible, package-independence processing by the user. (See also the autoconf-list archived message: "Re: nonstandard library directories" (Bob Proulx, Thu, 29 Jun 2006 21:38:15 -0600): http://lists.gnu.org/archive/html/autoconf/2006-06/msg00122.html ) It seems one possibility would be a command such as ./configure CLN="C:/gnu/cln-1.1.11/gcc342" READLINE="C:/gnu/readline-5.1/gcc342" TERMCAP="C:/gnu/termcap-1.3.1/gcc342" This would of course require adjusting the GiNaC distribution appropriately. (Generally, I'm thinking that there should be some easy, simple way of pointing to the various original package installation directories.) The advantage of this approach is that it allows the various library build/installation packages to be storage-wise independent of any centralized hierarchy such as "C:\Dev-Cpp", "C:\cygwin", or MinGW's "C:\msys", and thus would allow for easier systems-packages management. Another improvement that seems a good idea is in general to place a single value -- such as, for example, the configure script's option value of "--prefix" -- in one standard location that all Makefiles would refer to, so that the user could simply modify that one value for all Makefiles, in contrast to the present practice of repetitively placing a given such value in every Makefile. There are other files -- for example, script file "config.status" -- that also refer to the "--prefix" value and would also need to be modified to refer to the one, central, GiNaC-build information file for this information. Of course, such a facility should also be described sufficiently in the INSTALL file. (While "make install prefix=/path/to/wherever" may be a good work-around for the "--prefix" value, there are many other values which are repetitively placed throughout the Makefiles and which may need to be modified; or perhaps they too could be treated similarly to the "prefix=" example. But it is important to include that information in the INSTALL file.) The idea, of course, is to improve the ease and flexibility of the build process, especially when bugs are encountered and especially in view of the fact that configure is a rather time-consuming script to run and that building the library object files and building the libraries after the object files are built are also time-consuming, and even some of the tests are a bit time-consuming as well. I would like to hear what others think of the general idea and various practices in managing software packages to be as mutually independent as possible, except where dependence is really needed. This is particularly important in regard to GiNaC builds and installations -- as well as other software package builds and installations. I would also like to hear how this idea could or should be implemented for GiNaC, especially along the lines suggested above, or what alternative considerations and practices my be more appropriate. Please note that, while many of the above details may seem irrelevant from certain limited perspectives, I am supplying these details to give a realistic idea of what a new user is faced with. (And while the examples given above are specific to "C:\Dev-Cpp", "C:\cygwin", or MinGW's "C:\msys" in a Windows environment, the general issue of systems-packages independence seems equally applicable to standard Unix/Linux systems as well; but in the case of Unix, it seems there is a whole lot of "ancient" systems legacy -- e.g., centralized installation -- that may perhaps also need to be considered.) As experience shows, it seems to me that the build process needs to be designed to allow for the possibilities that bugs will appear and that a relatively build-unspecialized user needs to respond to those bugs in a flexible manner. Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Results of GiNaC (& CLN) builds
by Richard Haney 06 Aug '06

06 Aug '06

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(a)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

4 21