[GiNaC-list] Results of GiNaC (& CLN) builds

[Richard Haney]

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