superfluous /usr/lib/*.so symbolic links

Greg Schafer gschafer at zip.com.au
Fri Sep 13 14:21:39 PDT 2002


On Fri, Sep 13, 2002 at 03:01:20PM -0400, Gerard Beekmans wrote:
> On September 13, 2002 09:32 am, Jack Brown wrote:
> >     I noticed in the CVS changelog that Gerard decided to remove one of the
> > sets of .so symlinks from some of the packages. from what I can tell by
> > browsing through the ncurses instructions, the wrong set of symlinks were
> > deleted.  As far as I understand, the .so symlinks in /lib are the ones
> 
> I'm not suprised I messed it up again. Though, don't look at how Glibc does 
> it, it doesn't do things entirely "correct" (as far as you can speak of 
> correct and incorrect). It has its own way of doing things so we just ignore 
> Glibc and let it be.
> 
> Having that said, it's a little bit late for me to redo the symlinks. I admit 
> I didn't really think much what I was doing, just removing some, what seemed 
> to be, cruft from /usr/lib
> 
> It doesn't cause any problems the way things are at the moment and I don't 
> want to postpone the LFS-4 release because of it. We'll fix it up later.

Hrm, just having taken a quick peek at the ncurses commands, I have to agree
with Jack.

I could be wrong, but it looks like linking against ncurses will only
link against the *.a static lib. ie: apps won't link against the shared
lib ? Not good.

Maybe a quick ldd /bin/bash or ldd /sbin/cfdisk will show if that's the case?
I'm not in a position to test right now..

Greg
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list