Hi! Bernd Speiser wrote:
In config.log, I find:
configure:22950: checking for readline in -lreadline configure:22980: g++ -o conftest -g -O2 conftest.cc -lreadline >&5 /usr/local/lib/libreadline.so: undefined reference to `PC' /usr/local/lib/libreadline.so: undefined reference to `tgetflag' /usr/local/lib/libreadline.so: undefined reference to `tgetent' /usr/local/lib/libreadline.so: undefined reference to `UP' /usr/local/lib/libreadline.so: undefined reference to `tputs' /usr/local/lib/libreadline.so: undefined reference to `tgoto' /usr/local/lib/libreadline.so: undefined reference to `tgetnum' /usr/local/lib/libreadline.so: undefined reference to `BC' /usr/local/lib/libreadline.so: undefined reference to `tgetstr' collect2: ld returned 1 exit status
which suggests that libreadline is looked for in /usr/local/lib, but not in /lib. Can this behavior be changed?
Not even installing libreadline in /usr/local/lib like
# ll /usr/local/lib/*readline* -rw-r--r-- 1 root root 659580 Nov 13 10:54 /usr/local/lib/libreadline.a lrwxrwxrwx 1 root root 16 Nov 13 10:54 /usr/local/lib/libreadline.so -> libreadline.so.5 lrwxrwxrwx 1 root root 18 Nov 13 10:54 /usr/local/lib/libreadline.so.5 -> libreadline.so.5.2 -r-xr-xr-x 1 root root 484002 Nov 13 10:54 /usr/local/lib/libreadline.so.5.2
does help.
Any suggestion, what could be the reason?
Those unresolved symbols are all supposed to be provided by libncurses. Actually, the dynamic libreadline should be linked against libncurses. If linking against a dynamic libreadline fails to pull in libncurses, then libreadline is broken or not installed correctly. Which suggest you should fix the installation of libreadline. (Alternatively, you may be able to export LDFLAGS="-lncurses" or similarly, but that is a hack.) Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>