libcurses.so -> libncurses.so symlink and ldconfig
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):
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 :-(
More information about the lfs-dev