Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: mea@sparta.com (Mike Anderson)
Newsgroups: comp.sys.sun
Subject: ld.so looks for wrong libc.so
Keywords: Miscellaneous
Message-ID: <2005@brchh104.bnr.ca>
Date: 19 Mar 91 18:33:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 26
Approved: Sun-Spots@rice.edu
X-Original-Date: Mon, 11 Mar 91 11:49:51 EST
X-Sun-Spots-Digest: Volume 10, Issue 58, message 9
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

I have run across a rather strange situation.  I have 4.1.1 on one of my
disks and I have 4.1.1 coming.  Unfortunately, Sun's update service is now
claiming that they only ship 4.1.1 on CD ROM and we are a long way away
from being able to get a CD ROM drive (we have the money, but Sun's lead
times mean that we won't see it for weeks :-\ ).

I just got a new 669 MB disk for my SLCs and I wanted to get 4.1.1 on it.
Lacking a CD ROM drive, I thought to try to attach the new disk to my
current SCSI bus and use dump to get the OS on the new disk.  I formatted,
partitioned, used dump to copy over everything, installed the boot block
and everything looked good.  I put the new disk onto my SLC and voila, it
booted.

Now comes the strange part.  When I try to run certain programs like vi, I
get a message from ld.so saying it can't find libc.so.2 and the program
sputters and dies.  Now when I look at my /usr/lib, I see libc.so.1.6 but
no libc.so.2.  The ld.so.cache looks right (it shows libc.so.1.6) as does
LD_LIBRARY_PATH.  Issueing ldconfig doesn't clear it up either.  Reboots
are ineffective at clearing this problem up as well.  Anyone have any
clues, pointers or RTFMs they can give me to shed some light on this
problem?

Thanks in advance.

Mike Anderson
mea@sparta.com