From owner-freebsd-hackers Mon Apr 1 10:55:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA17041 for hackers-outgoing; Mon, 1 Apr 1996 10:55:48 -0800 (PST) Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA17035 for ; Mon, 1 Apr 1996 10:55:44 -0800 (PST) Received: from newport.ece.uci.edu by meter.eng.uci.edu (8.7.4) id KAA06942; Mon, 1 Apr 1996 10:55:41 -0800 (PST) Received: from localhost by newport.ece.uci.edu (8.7.4) id KAA23534; Mon, 1 Apr 1996 10:55:39 -0800 (PST) Message-Id: <199604011855.KAA23534@newport.ece.uci.edu> To: Warner Losh cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: libc 3.0 In-reply-to: Your message of "Sun, 31 Mar 1996 19:52:02 MST." <199604010252.TAA11391@rover.village.org> Date: Mon, 01 Apr 1996 10:55:37 -0800 From: Steven Wallace Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Finally, I get the impression that I'm the only one that seems to > think this is a problem. If so, I'll go away, but I've seen only two > or three messages in hackers. I think this is really important. > > Comments? > You are right. This is important and the make world of take a few extra steps. You were on the right track. Just move ld.so.3.0 into /usr/lib/junk and then do an ldconfig /usr/lib /usr/lib/junk ... When ld comes along to link stuff, it does not see ld.so.3.0 'cuz it's in junk dir. You also said: >I didn't say that they would be proud of it [hack], but sometimes you gotta >do gross things to keep binary compatibility. > >If there were a boatload of other changes in this release, then it >wouldn't be a big deal. If the only reason to bump the major rev was >for NETISO and NETNS stuff that was killed (which was sold as not >impacting anybody), then some allowances should be made. I agree completely! In a scrict sense, bumping the major version is the correct thing to do, but in a practical sense leaving it as version 2 for binary compatability outweighs the correctness of going to ver 3. I call for the changes Warner and I have proposed. Let us revert to ver 2.3 and let -current people follow the reversion procedure I outlined. When we move to ELF binaries and libraries, THEN we should remove those old net functions when we are forced to go to a new library version. Steven