-> symlink and ldconfig

Greg Schafer gschafer at
Thu Aug 4 16:00:43 PDT 2005

Alexander E. Patrakov wrote:

> lrwxrwxrwx  1 root root     12 Jun 23 12:14 ->
> 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 -> symlink can be replaced 
> with a simple linker script:
> rm
> rm
> echo 'INPUT(-lncurses)' >
> 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 mailing list