From owner-freebsd-bugs Mon Jul 8 21:32:00 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA10929 for bugs-outgoing; Mon, 8 Jul 1996 21:32:00 -0700 (PDT) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA10914 for ; Mon, 8 Jul 1996 21:31:54 -0700 (PDT) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id AAA18230; Tue, 9 Jul 1996 00:30:29 -0400 From: Bill Paul Message-Id: <199607090430.AAA18230@skynet.ctr.columbia.edu> Subject: Re: 2.1-960627-SNAP: YP problem To: mikebo@tellabs.com Date: Tue, 9 Jul 1996 00:30:28 -0400 (EDT) Cc: bugs@freebsd.org In-Reply-To: <199607090336.WAA21151@sunc210.tellabs.com> from "mikebo@tellabs.com" at Jul 8, 96 10:36:49 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, mikebo@tellabs.com had to walk into mine and say: > Jordan, et al. wrote: > > > > > Installing compatibility options should install the 1.1 and 2.0 libs, > > > but shouldn't trash the 2.2 lib, should it? > > > > No, and it didn't. What makes you think that it did? > > > 'Cuz Gary wrote: Uh, I'm Bill, not Gary. :) > > The result is that if you somehow managed to keep an older version of > > libc.so around (like from the previous SNAP) you might have conflicts since > > the older getpwent(3) NIS code is not strictly forward compatible > > and his libc.so.2.2 has a newer date (by several months), and is bigger > (by a few hundred bytes). If this doesn't this mean I have an out-of-date > libc.so.2.2, it's at least *different* than Gary Palmer's "reference" box. > How exactly it's different I don't know, but an April libc in a July SNAP > is kinda suspicious, no? > > > marple# ls -l /usr/lib/libc.* > > -r--r--r-- 1 bin bin 497710 Jun 28 04:44 /usr/lib/libc.a > > -r--r--r-- 1 bin bin 435727 Jun 28 04:44 /usr/lib/libc.so.2.2 Notice also that the timestamps on both my libraries match. In your case, libc.so.2.2 and libc.a should match but they don't. (Your libc.a looks correct however.) > toybox> ls -l /usr/lib/libc.* > -r--r--r-- 1 bin bin 497710 Jun 28 03:44 /usr/lib/libc.a > -r--r--r-- 1 bin bin 403106 Jul 3 1994 /usr/lib/libc.so.1.1 > -r--r--r-- 1 bin bin 466907 Jan 25 1995 /usr/lib/libc.so.2.0 > -r--r--r-- 1 bin bin 435248 Apr 27 16:57 /usr/lib/libc.so.2.2 > > Please excuse me if I'm making no sense... I've been at work since > 0800 and it's now 2230. I guess I'm grasping for anything that might > explain my NIS woes. I think you do have a bogus libc.so.2.2, however I can't explain how you got it. The compat distribution is supposed to add the two older libraries (I guess) not replace the 'standard' one. (Note that I did do a custom install on my box: I specifically selected the bin, man, games, dict and des distributions and nothing else. Anyway, here's how you can try to fix this: get the bin distribution (bin.aa through bin.whatever) and extract the libc.so.2.2 from there. The distribution is basically one giant tar.gz archive. You can extract a single file from it like this: % cat bin.?? | gzip -d | tar -xf - usr/lib/libc.so.2.2 Replace your existing libc.so.2.2 with this one (this is best done from single user mode) and then see if NIS works. Ideally, it should. I still can't figure out how the test program seemed to work before though. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================