From kreckel at ThEP.Physik.Uni-Mainz.DE Mon Jan 10 15:33:16 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Mon, 10 Jan 2000 15:33:16 +0100 (CET) Subject: GiNaC porting status Message-ID: I once wrote about 64-bit issues and that GiNaC builds fine on Linux/AXP except for shared libraries, where everything segfaulted immediately. Somebody guessed we were suffering from some "static initialization order fiasco". I haven't looked into that since then---which is good, since I just came across this quote from the current GCC caveats list : : Exception handling may not work with shared libraries, particularly on : alphas, hppas, rs6000/powerpc and mips based platforms. Exception : handling is known to work on x86 GNU/Linux platforms with shared : libraries. So, it's not our problem, is it? Doesn't sound good, though. Happy hacking -rbk. -- Richard Kreckel From kreckel at ThEP.Physik.Uni-Mainz.DE Wed Jan 12 02:17:47 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Wed, 12 Jan 2000 02:17:47 +0100 (CET) Subject: ToDo-list Message-ID: Good morging, Higher forces (drunken collegues) have just urged me to send this mail to the list: ;*) Today I have written a little summary about possible future extensions of GiNaC accessible at . Feel free to comment on it. regards -rbk. PS: I have been wondering for a while about ASSERT. Don't we need two different kinds of assertions? One for things within the library like the GINAC_ASSERT(is_canonical()); at line 94 in ginac/mul.cpp and one like the GINAC_ASSERT(is_exactly_of_type(other, matrix)); at line 255 in matrix.cpp? (Both lines refer to current CVS stuff.) The first one marks an oops that can only happen to developers of the library, the second can happen to anybody. In a distribution, the first one may be ommitted from the normal runtime-library, but not the second, which may not even be fatal but only issue a warning. Maybe we do need a soft and a hard ASSERT??? -- Richard Kreckel From cbauer at ThEP.Physik.Uni-Mainz.DE Wed Jan 12 13:47:01 2000 From: cbauer at ThEP.Physik.Uni-Mainz.DE (Christian Bauer) Date: Wed, 12 Jan 2000 13:47:01 +0100 (CET) Subject: ToDo-list In-Reply-To: Message-ID: Hi! On Wed, 12 Jan 2000, Richard B. Kreckel wrote: > One for things within the library like > the GINAC_ASSERT(is_canonical()); at line 94 in ginac/mul.cpp and one > like the GINAC_ASSERT(is_exactly_of_type(other, matrix)); at line 255 > in matrix.cpp? (Both lines refer to current CVS stuff.) The first > one marks an oops that can only happen to developers of the library, > the second can happen to anybody. Really? Isn't compare_same_type() intended as an internal library function? Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ From jgreco at siichi.com Wed Jan 19 00:04:33 2000 From: jgreco at siichi.com (Jeff Greco) Date: Tue, 18 Jan 2000 17:04:33 -0600 Subject: Undefined symbols for ginsh Message-ID: <93D41A0914BAD211A0FA00A0C955A6EB365A3D@goliath.siichi.com> To Whom It May Concern: I am using: Operating system: SunOS samsun 5.6 Generic_105181-03 sun4u sparc SUNW,Ultra-Enterprise Compiler: egcs-2.91.57 CLN: version 1.0.2 CLN and GiNaC are configured with default settings, except that CLN is only shared libraries. My linker is complaining about undefined symbols in 'ginsh_parser.o'. Any way that you can help is greatly appreciated. Here is the output from make: make all-recursive make[1]: Entering directory `/dumptruck/GiNaC-0.4.1' Making all in ginac make[2]: Entering directory `/dumptruck/GiNaC-0.4.1/ginac' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/dumptruck/GiNaC-0.4.1/ginac' Making all in check make[2]: Entering directory `/dumptruck/GiNaC-0.4.1/check' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/dumptruck/GiNaC-0.4.1/check' Making all in ginsh make[2]: Entering directory `/dumptruck/GiNaC-0.4.1/ginsh' /bin/sh ../libtool --mode=link g++ -g -O2 -o ginsh ginsh_parser.o ginsh_lexer.o ../ginac/libginac.la -lcln -lstdc++ g++ -g -O2 -o .libs/ginsh ginsh_parser.o ginsh_lexer.o ../ginac/.libs/libginac.so -lcln -lstdc++ -lcln -lstdc++ -R/usr/local/lib Undefined first referenced symbol in file rl_basic_word_break_characters ginsh_parser.o rl_readline_name ginsh_parser.o filename_completion_function ginsh_parser.o completion_matches ginsh_parser.o rl_completion_append_character ginsh_parser.o rl_line_buffer ginsh_parser.o rl_attempted_completion_function ginsh_parser.o ld: fatal: Symbol referencing errors. No output written to .libs/ginsh collect2: ld returned 1 exit status make[2]: *** [ginsh] Error 1 make[2]: Leaving directory `/dumptruck/GiNaC-0.4.1/ginsh' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/dumptruck/GiNaC-0.4.1' make: *** [all-recursive-am] Error 2 Thanks, Jeff Greco Jgreco at siichi.com From kreckel at ThEP.Physik.Uni-Mainz.DE Wed Jan 19 19:36:18 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Wed, 19 Jan 2000 19:36:18 +0100 (CET) Subject: Undefined symbols for ginsh In-Reply-To: <93D41A0914BAD211A0FA00A0C955A6EB365A3D@goliath.siichi.com> Message-ID: On Tue, 18 Jan 2000, Jeff Greco wrote: [...] > make[2]: Entering directory `/dumptruck/GiNaC-0.4.1/ginsh' > /bin/sh ../libtool --mode=link g++ -g -O2 -o ginsh ginsh_parser.o > ginsh_lexer.o ../ginac/libginac.la -lcln -lstdc++ > g++ -g -O2 -o .libs/ginsh ginsh_parser.o ginsh_lexer.o > ../ginac/.libs/libginac.so -lcln -lstdc++ -lcln -lstdc++ > -R/usr/local/lib > Undefined first referenced > symbol in file > rl_basic_word_break_characters ginsh_parser.o > rl_readline_name ginsh_parser.o > filename_completion_function ginsh_parser.o > completion_matches ginsh_parser.o > rl_completion_append_character ginsh_parser.o > rl_line_buffer ginsh_parser.o > rl_attempted_completion_function ginsh_parser.o > ld: fatal: Symbol referencing errors. No output written to .libs/ginsh > collect2: ld returned 1 exit status > make[2]: *** [ginsh] Error 1 > make[2]: Leaving directory `/dumptruck/GiNaC-0.4.1/ginsh' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/dumptruck/GiNaC-0.4.1' > make: *** [all-recursive-am] Error 2 These are all symbols from libreadline. Please find the place this library is sitting at on your system and link explicitly against it by adding either -lreadline or /path/to/readline.a to the command that starts with `g++ -g -O2...' above. If you cannot find this libaray, you may get it from , compile and install it. HTH. (BTW: It's only ginsh that uses libreadline for command-line editing, completion and such. The rest of GiNaC works without it.) Regards -rbk. PS: BTW, you have probably received warnings like this one when configuring GiNaC: checking for readline/readline.h... no checking for readline in -lreadline... no PPS: Just to make sure, since you have the SPARC/EGCS-2.91.xx combination: You did add `-O2 -fno-schedule-insns' to the CXXFLAGS when you compiled CLN, didn't you? Personally, I don't know of anybody who has tried out GiNaC on such a system yet, but I don't know why it shouldn't work. Can you please drop me a note when you find out it's working? -- Richard Kreckel From cbauer at ThEP.Physik.Uni-Mainz.DE Wed Jan 19 21:18:43 2000 From: cbauer at ThEP.Physik.Uni-Mainz.DE (Christian Bauer) Date: Wed, 19 Jan 2000 21:18:43 +0100 (CET) Subject: Archiving of expressions Message-ID: Hi! The long-awaited archiving (aka I/O) of expressions is now implemented in the latest CVS version (except for the classes idx and structure and all classes derived from idx and indexed, because these seem still to be undergoing changes). A new chapter in the tutorial explains how to use the new features. There is now a global registry (implemented in registrar.*) for all archivable classes (= basic and derived classes). To implement archiving for you classes, do the following: - add the GINAC_DECLARE_REGISTERED_CLASS(foo, bar) line to the beginning of the class declaration - add the GINAC_IMPLEMENT_REGISTERED_CLASS(foo, bar) line to the beginning of the *.cpp file of the class - implement the unarchiving constructor and the archive() and unarchive() member functions in your class If your class doesn't add any member variables to its superclass which have to be stored in the archive, you must at least call the unarchiving constructor and the archive() function of the superclass (see add.cpp for an example of how to do this minimal implementation of archiving). If you _do_ have member variables which need to be stored, they have to be added to the archive_node in the archive() function and retrieved from there in the unarchiving constructor (see power.cpp for a simple example, matrix.cpp for a more complex one). The unarchive() function is almost always the same in all classes (for exceptions, see symbol.cpp and constant.cpp). Unarchiving of constants is currently sub-optimal. Only the three constants that we provide (Pi, Catalan, EulerGamma) can be unarchived. A global registry for all existing constants should be implemented. Also, archiving floating-point numbers will lose precision (because they are stored as a decimal fraction). This is being worked on. The small program "viewgar" in the tools directory is a stand-alone viewer for archive files. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/