libcurses.so -> libncurses.so symlink and ldconfig

Greg Schafer gschafer at zip.com.au
Thu Aug 4 16:00:43 PDT 2005


Alexander E. Patrakov wrote:

> lrwxrwxrwx  1 root root     12 Jun 23 12:14 libncurses.so.5 -> libcurses.so
> 
> Note the last symlink (created by ldconfig).

Hmmm, well spotted. I'd never noticed it before..

> I don't know if it is a 
> real problem (but it sometimes shows e.g. in ldd /bin/bash on 
> glibc-2.3.5 based systems).

I don't see it in ldd output.

> If this symlink is indeed bad, it can be 
> removed and the libcurses.so -> libncurses.so symlink can be replaced 
> with a simple linker script:
> 
> rm libncurses.so.5
> rm libcurses.so
> echo 'INPUT(-lncurses)' >libcurses.so
> 
> If the symlink is a non-problem, sorry for the noise.

IMHO it looks like a problem in Glibc ie: ldconfig, albeit a minor one.
These 2 threads are relevant (I think):

  http://sources.redhat.com/ml/libc-alpha/2003-07/msg00098.html
  http://sources.redhat.com/ml/libc-alpha/2003-08/msg00120.html

But trying to prove Glibc bug's to upstream dev's can be a challenge :-/

Your proposed workaround may well work, but...

Why do we install the symlink anyway? Only because the default ncurses
installation installs a libcurses.a -> libncurses.a symlink and any
software that tries to link against -lcurses would link against the static
lib instead of against the shared one. I suppose the real question is, do
we really need the ability to link against -lcurses? Surely most stuff
these days will link against -lncurses? If we don't need the ability to
link against -lcurses then the solution is simple. Just rm the libcurses.a
-> libncurses.a symlink. I suppose the only way to find out would be to
build a full distro with that change and see what breaks. No easy task :-(

Regards
Greg
--
http://www.diy-linux.org/




More information about the lfs-dev mailing list