From: Neil Jerram <neil@ossau.uklinux.net>
To: Frank J.R.Hanstick <trog24@comcast.net>
Cc: Guile User List <guile-user@gnu.org>
Subject: Re: Compilation failure.
Date: Mon, 29 Jun 2009 21:55:53 +0100 [thread overview]
Message-ID: <87skhivjxi.fsf@arudy.ossau.uklinux.net> (raw)
In-Reply-To: <92338D2C-2E45-43A4-B4A7-AF5CAD54BF38@comcast.net> (Frank J. R. Hanstick's message of "Fri\, 30 May 2008 03\:55\:11 -0700")
Frank J. R. Hanstick <trog24@comcast.net> 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
next prev parent reply other threads:[~2009-06-29 20:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-28 12:53 Compilation failure Frank J. R. Hanstick
2008-05-28 13:59 ` Neil Jerram
[not found] ` <92338D2C-2E45-43A4-B4A7-AF5CAD54BF38@comcast.net>
2009-06-29 20:55 ` Neil Jerram [this message]
[not found] ` <87prcmpwtt.fsf@gnu.org>
[not found] ` <87fxdivhki.fsf@arudy.ossau.uklinux.net>
2009-06-30 22:17 ` Neil Jerram
2008-05-28 14:02 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87skhivjxi.fsf@arudy.ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=guile-user@gnu.org \
--cc=trog24@comcast.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).