Date: Wed, 15 Nov 2000 15:24:00 -0800 From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) To: Jordan Hubbard <jkh@winston.osd.bsdi.com> Cc: stable@FreeBSD.ORG Subject: Re: libc shlib version Message-ID: <vqc1ywcsttb.fsf@silvia.hip.berkeley.edu> In-Reply-To: <47225.974328301@winston.osd.bsdi.com> (Jordan Hubbard's message of "Wed, 15 Nov 2000 14:45:01 -0800") References: <obrien@FreeBSD.ORG> <47225.974328301@winston.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* From: Jordan Hubbard <jkh@winston.osd.bsdi.com> * 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?vqc1ywcsttb.fsf>