Frank J. R. Hanstick <[email protected]> writes: > Hello, > Thank you for responding.
Hi Frank, Here's another response, but I'm afraid a very late one... I've added CC to the list, for the record and for other MacOS users. > I went to > http://www.gnu.org/software/guile/docs/faq/guile-faq.html (the FAQ > pointed to from http://www.gnu.org/software/guile/ guile.html) and > searched for the error and it was no where to be found. I then went > to http://www.gnu.org/software/guile/docs/faq/OLD- > guile-faq.html and came up with the same result. I had done this > before emailing; but, did it again just to be sure I had not missed > anything. Is there another FAQ page? Yes, there was, in the Guile distribution itself. But I see now that this was confusing, so I've removed it that file and merged the information that was in it (about Readline/Editline) into http://www.gnu.org/software/guile/docs/faq/guile-faq.html. > libedit was installed. The source of the installation is most > likely Darwin since I had not installed anything BSD related since > installing the MacOS. There was no readline installed; therefore, I > installed readline-5.2. That corrected the rl_pending_input" error; > but, now get the following: > > ld: warning multiple definitions of symbol _rl_free_line_state > .libs/readline.o definition of _rl_free_line_state in section > (__TEXT,__text) > /usr/local/lib/libreadline.dylib(signals.so) definition of > _rl_free_line_state > ld: warning multiple definitions of symbol _rl_cleanup_after_signal > .libs/readline.o definition of _rl_cleanup_after_signal in section > (__TEXT,__text) > /usr/local/lib/libreadline.dylib(signals.so) definition of > _rl_cleanup_after_signal Those multiple definitions would occur if libreadline was being picked up during the build but not when configure was run. Could you consider - looking at the part of guile-readline/config.log that covers looking for rl_cleanup_after_signal, to see if there are any clues there - running configure again with CPPFLAGS and LDFLAGS set like this: CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure [your usual options] > ld: warning multiple definitions of symbol _PC > /usr/local/lib/libreadline.dylib(terminal.so) definition of _PC > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib > (lib_tputs.o) definition of _PC > ld: warning multiple definitions of symbol _UP > /usr/local/lib/libreadline.dylib(terminal.so) definition of _UP > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib > (lib_termcap.o) definition of _UP > ld: warning multiple definitions of symbol _BC > /usr/local/lib/libreadline.dylib(terminal.so) definition of _BC > /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib > (lib_termcap.o) definition of _BC I don't know about these, but it looks as though libreadline.dylib already includes those curses symbols. Maybe the -lncurses isn't needed on MacOS? Based on Guile's guile-readline/configure.in and Gnulib's readline.m4, it looks like that might be the case. guile-readline/configure.in tries pretty hard to find and use a curses library: for termlib in ncurses curses termcap terminfo termlib ; do AC_CHECK_LIB(${termlib}, tgoto, [LIBS="-l${termlib} $LIBS"; break]) done but Gnulib is more careful: dnl On some systems, -lreadline doesn't link without an additional dnl -lncurses or -ltermcap. dnl Try -lncurses before -ltermcap, because libtermcap is unsecure dnl by design and obsolete since 1994. Try -lcurses last, because dnl libcurses is unusable on some old Unices. for extra_lib in "" ncurses termcap curses; do LIBS="$am_save_LIBS $LIBREADLINE" if test -n "$extra_lib"; then LIBS="$LIBS -l$extra_lib" fi AC_TRY_LINK([#include <stdio.h> #include <readline/readline.h>], [readline((char*)0);], [gl_cv_lib_readline=" -l$extra_lib"]) if test "$gl_cv_lib_readline" != no; then break fi done Probably Guile (1.8.x) should be do the same as Gnulib does. If you're still in a position to try that out, I'll work out a patch. Regards, Neil
