Or: Why GiNaC builds have not been straightforward It turns out that when the configure script tests for the existence of a usable readline function, it specifies -lreadline but not -ltermcap or the "curses" library, but modules in the readline static library apparently call functions that are not resolved by the linker. Those references are resolvable with the termcap library. (Readline installation documentation seems to say that the curses library can be used as an alternative to the termcap library.) A simple test program links quite well when both -readline and -ltermcap are properly specified. And by extracting the three object modules in libtermcap.a and inserting them in libreadine.a and by using this expanded libreadline.a, I was able to get the "make", "make check", and "make install" procedures to proceed without any need for modification of Makefiles; I did specify "--prefix=..." on the configure command line. (However, I did have to restart "make" because of errors due to timing out of subprocesses when the computer was put into hibernation; but there appears to be no deleterious effect as a result, and I had to copy my modified ginsh/ginsh_parser.cc from a previous build and either Sheplyakov's patched or my patched check/timer.h and check/timer.cpp as well as ginac/indexed.cpp with the assertion at line 701 commented out, and also Sheplyakov's patched "check/exam_archive.cpp".) Note that there seems to be no problem with unsatisfied "termcap" references when using the libreadline.5.dll and libhistory.5.dll that's created in the readline build, but of course, the configure script looks for libreadline.a, not libreadline.5.dll . One must manually modify ginsh/Makefile in order to use the .dll . So it would seem that the configure script should be modified to insert a -ltermcap or -lcurses (if that's the right name) -- or both (?) -- in the linker command line to test for readline, depending on what the script has found by prior tests -- or simply leave it a -lreadline only if neither of these extra libraries is found. If the unsatisfied references would never be needed for program flow, perhaps an option could be added to the linker command line to allow unresolved references (if there is such an option), or perhaps both -ltermcap and -lcurses could be specified along with an option to simply allow multiply-defined symbols and thus perhaps avoid any logic/decision-making fuss over which library should be used. These are just suggestions as to possibilities; I'm not familiar with the details here. Surprisingly, the unmodified ginsh/Makefile does put both -lreadline and -ltermcap on the linker command line to build ginsh. So it seems that -ltermcap was probably just inadvertently omitted in the configure script to test for the readline function. And incidentally, this supposed need for termcap seems to be counter to a comment and patch by Sheplyakov Alexei to the effect that termcap is being phased out; the details of this I'm not familiar with. Also, I used none other of Sheplyakov's and my patched files in GiNaC for this test run than those I specifically mentioned above as needing to be copied from a previous build. As for design of the configure script, it seems best that it should set the readline macros in config.h based on the headers found, regardless of whether a usable readline function is found. That would tend to simplify any debugging and manual adjustments needed when such a usable readline function is not found. But of course this would depend on the likelihood of various problematical states/scenarios when a usable readline function is not found. Incidentally, quite a bit of manual intervention, especially Makefile modification, was needed in building the readline/history libraries. Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com