From owner-freebsd-stable Wed Nov 15 16: 2: 4 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id 282EE37B4CF for ; Wed, 15 Nov 2000 16:02:01 -0800 (PST) Received: from silvia.hip.berkeley.edu ([64.161.28.80]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G4300N4PAAJ0P@mta5.snfc21.pbi.net> for stable@FreeBSD.ORG; Wed, 15 Nov 2000 15:23:08 -0800 (PST) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.11.1/8.11.0) id eAFNO2942158; Wed, 15 Nov 2000 15:24:02 -0800 (PST envelope-from asami@cs.berkeley.edu) Date: Wed, 15 Nov 2000 15:24:00 -0800 From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Subject: Re: libc shlib version In-reply-to: <47225.974328301@winston.osd.bsdi.com> (Jordan Hubbard's message of "Wed, 15 Nov 2000 14:45:01 -0800") To: Jordan Hubbard Cc: stable@FreeBSD.ORG Message-id: MIME-version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-type: text/plain; charset=US-ASCII User-Agent: T-gnus/6.14.5 (based on Gnus v5.8.7) (revision 06) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 =?ISO-2022-JP?B?KBskQjJWMWMbKEIp?= Lines: 51 References: <47225.974328301@winston.osd.bsdi.com> X-Authentication-warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * From: Jordan Hubbard * So this sounds to me like we no longer need to bump it? I wish * everyone could just make up their minds! Sorry if you got the impression that it was me causing the holdups. I do not fully understand the situation so I thought I deffered to David. (I stopped being a shared library expert when we switched from a.out to ELF. :) * If we haven't changed any * interfaces in -stable since 4.1 then we don't need to bump anything. * If we have, we do, that's just how shared library versions work. I * don't understand all this prevarication over what would be "easy" or * "difficult" since the rules on this have always been crystal clear: * You change a library interface, you bump the number. If you change * those interfaces in between every release, then you're stupid and * deserve to lose but you still gotta bump the number. Yes, in order to avoid accidental system destruction because people moved supposedly "compatible" libraries around (like what happened with the 40upgrade kit), we need to bump the number. However, since the change was (apparently -- nobody has verified this yet) accompanied by a kernel interface change, changing the shlib number probably will not help the upgrade kit. The new libc.so.5 will not be able to run with a 4.0R kernel anyway, just like the new libc.so.4 (which is exactly the same now as what libc.so.5 will be) is dumping core all over the place when matched up with a 4.0R kernel. At least that's my understanding based on David's explanation. If anyone has a 4.0R machine to test, I can send you a new libc.so.5 and a couple of binaries compiled against it, so we can see if it really works. (No, it will not destroy your system...trust me!) * What I haven't understood at any point is just what the hell changed * and why Roger Hardiman's packages broke. Anybody care to clear this * up? I'm starting to wonder if we've simply been chasing a red herring * the whole time and the problem has nothing to do with this since * nobody involved can state anything definitive as to WHY this has to * happen or even what was changed. Roger's packages is a different issue, that one was in libc_r. According to him, it was caused by the pthread merge that occurred too late for him to fix his ports before the (initial) ports freeze. Hmm. Now that I think about it, since this one is a pure backward-incompatible library interface change, do we need to bump libc_r's version number? Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message