[GiNaC-list] GiNaC vs readline [Was: Problems]

[David Fang]

> On Mon, Jan 29, 2007 at 11:17:34PM -0500, David Fang wrote:
> > The reason the above is happening is because your configure found
> > /usr/include/readline and /usr/lib/libreadline which (on Mac OS X) is
> > actually the BSD editline or histedit wrapper library (almost readline).
>
> Thank you very much for investigation.
>
> > 	A real solution requires accommodating the possibility of
> > non-numeric version string in the config.h header or re-writing the test
> > so that it is not a problem.
>
> Here is really dumb patch which does this:
>
> [PATCH] Fix libreadline version detection.
>
> Some vendor-supplied readline equivalents (e.g. one on Mac OS X)
> return non-numeric rl_library_version. Let's check for such
> an ill-formed version string. For now I assume that such a library
> is compatible with GNU readline 4.2.

Hi,
	Unfortunately, the problems don't stop there:

----------->8 snip 8<-------------
f g++ -DHAVE_CONFIG_H -I. -I../../ginsh -I.. -I../../ginsh/../ginac
-I../ginac -DIN_GINAC  -I/usr/local/include -I/sw/include  -g -O2 -MT
ginsh_parser.o -MD -MP -MF ".deps/ginsh_parser.Tpo" -c -o ginsh_parser.o
../../ginsh/ginsh_parser.cc; \
then mv -f ".deps/ginsh_parser.Tpo" ".deps/ginsh_parser.Po"; else rm -f
".deps/ginsh_parser.Tpo"; exit 1; fi
if g++ -DHAVE_CONFIG_H -I. -I../../ginsh -I.. -I../../ginsh/../ginac
-I../ginac -DIN_GINAC  -I/usr/local/include -I/sw/include  -g -O2 -MT
ginsh_lexer.o -MD -MP -MF ".deps/ginsh_lexer.Tpo" -c -o ginsh_lexer.o
../../ginsh/ginsh_lexer.cc; \
then mv -f ".deps/ginsh_lexer.Tpo" ".deps/ginsh_lexer.Po"; else rm -f
".deps/ginsh_lexer.Tpo"; exit 1; fi
../../ginsh/ginsh_parser.yy: In function 'char** fcn_completion(const
char*, int, int)':
../../ginsh/ginsh_parser.yy:858: error: invalid conversion from 'const
char*' to 'char*'
../../ginsh/ginsh_parser.yy:863: error: 'rl_filename_completion_function'
was not declared in this scope
../../ginsh/ginsh_parser.yy:863: error: 'rl_completion_matches' was not
declared in this scope
../../ginsh/ginsh_parser.yy:873: error: 'rl_completion_matches' was not
declared in this scope
make: *** [ginsh_parser.o] Error 1
 ----------->8 snip 8<-------------

Those three rl_ symbols also happen to be renamed without their "rl_"
prefixes in the editline wrapper header/library.  (I've found this problem
with old versions of GNU readline too, BTW.)  The workaround I devised in
the magic-7.1 source is the following:

#if defined(READLINE_4_DOT_2_PLUS) || (RL_VERSION_MAJOR >= 5) || (RL_VERSION_MAJOR == 4 && RL_VERSION_MINOR >= 2)
#define filename_completion_function rl_filename_completion_function
#define username_completion_function rl_username_completion_function
#define completion_matches rl_completion_matches
#endif

... and reference the names without "rl_" in source.  IIRC, the symbol
name broke from readline 4.1 to 4.2.  For my temporary workaround, I used
the reverse-definition of the above macros, using the non-rl_ symbols.
These particular editline wrappers might logically be based on
readline-pre-4.2 symbol names.  The non-reverse macros above allow better
link-ability with older readlines, or you could wrap the wrappers -- many
solutions exist, thanks to autoconf.

Assuming the completion function names are fixed, there's yet one more
problem:

editline defines the symbol
extern char             *rl_basic_word_break_characters;

but the source really wants a "const char*".

../../ginsh/ginsh_parser.yy:858: error: invalid conversion from 'const
char*' to 'char*'

There appears to be an attempt to detect this in the beginning of
ginsh_parser.yy.  By 'faking' the readline version to 4.1 in config.h, I
get the "const char*" declaration.

Then, ginsh compiles, links, and runs some basic commands with no
problems.  (This was using my bison-2.3 regenerated parser, since it
seems that 1.875 was mistaken.)

I hope this is enough information to fix things.  Depending on how the
developers want to handle the readline version fiasco (:D ?), various
patch solutions are at hand.  FWIW, my projects use separate
--with-readline=[PATH] and --with-editline=[PATH] style configure options
to distinguish between the libraries.  I got this idea from the ngspice
source tree.

Can you tell how much I love configuring for readline?  :P

Looking forward to testing the next RC.  :)
Cheers.


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
	-- (2400 baud? Netscape 3.0?? lynx??? No problem!)