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/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
