From owner-cvs-all@FreeBSD.ORG Fri Mar 18 16:32:56 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFF3216A4CE; Fri, 18 Mar 2005 16:32:56 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 632C443D53; Fri, 18 Mar 2005 16:32:56 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2IGV7fA039086; Fri, 18 Mar 2005 09:31:08 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <423B01C7.2030404@samsco.org> Date: Fri, 18 Mar 2005 09:28:55 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Warner Losh References: <423A8B51.3010609@portaone.com> <423A8DC5.5010006@samsco.org> <423A99CF.7010302@portaone.com> <20050318.092541.104079389.imp@bsdimp.com> In-Reply-To: <20050318.092541.104079389.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: danfe@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: sobomax@portaone.com cc: cvs-all@FreeBSD.org cc: das@FreeBSD.org Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2005 16:32:57 -0000 Warner Losh wrote: > From: Maxim Sobolev > Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h > Date: Fri, 18 Mar 2005 11:05:19 +0200 > > >>Scott Long wrote: >> >>>Maxim Sobolev wrote: >>> >>> >>>>Warner Losh wrote: >>>> >>>> >>>>>From: Maxim Sobolev >>>>>Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h >>>>>Date: Fri, 18 Mar 2005 09:44:25 +0200 >>>>> >>>>> >>>>> >>>>>>David Schultz wrote: >>>>>> >>>>>> >>>>>>>On Thu, Mar 17, 2005, Warner Losh wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>You had better bump the version number for libm before 6.0 rolls >>>>>>>>>around!! I've just found a 3rd party binary-only package that >>>>>>>>>supports 'FreeBSD 5.x' but is linked against libm.so.2. Ugh. We >>>>>>>>>need to bury that mistake and NOT make it again. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>6.0 already has /lib/libm.so.3 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>So does 5.3. I think Scott's point is that if we're going to bump >>>>>>>it for 6.X at all, we had better do it soon or risk running into >>>>>>>the same mess we had before. I agree with that, although at >>>>>>>present I don't know of a compelling reason to do the bump the >>>>>>>libm version number at all. >>>>>> >>>>>> >>>>>> >>>>>>Haven't several functions been removed from -CURRENT version of libm >>>>>>recently? IMHO this provides sufficient reason for version bump. >>>>>>Actually I think it makes sense to bump all libraries automatically >>>>>>when -CURRENT goes one major number up. There is just no much sense >>>>>>in preserving partial compatibility. >>>>> >>>>> >>>>> >>>>> >>>>>One of the problems with an overly agressive bumping is that if you >>>>>bump, you have to bump *EVERYTHING* that depends on the library to get >>>>>true compatbility, even the ports (and have different majors build >>>>>based on using libc.so.5 vs libc.so.6, a real pita). When I looked >>>>>into the major abi issues we had a while ago, I came to this >>>>>conclusion. I also came to the conclusion that we'd be better off >>>>>keeping compatibility and *NEVER* bumping a fundamental library's >>>>>major number to avoid these problems. Alas, no one listens to me, and >>>>>they make incompatible changes (like removing functions), so we're >>>>>stuck in the false belief that major numbers are going to save us.[*] >>>> >>>> >>>> >>>>What's the problem with ports? I think one who want to run older ports >>>>on newer system can install compatXX package, no? >>>> >>>>-Maxim >>> >>> >>>No, I think that what he's worried about is that you have port foo that >>>generates a library called libfoo.so.1, and that library is linked >>>against libm.so.2. You then have port bar that generates a binary >>>linked against libfoo.so.1 and libm.so.2. Now lets say that libm.so.2 >>>gets bumped to libm.so.3, and you also rebuild port bar. Now bar is >>>linked to libfoo.so.1 and libm.so.3, but libfoo.so.1 is still linked >>>against libm.so.2; mass panic ensues and the universe is driven into >>>chaos and death. >> >>I see, but this is non-issue, since actually the only sensible approach >>when going from release x.y to release x+1.y is to rebuild all >>third-party packages, at least ones that install shared libraries. The >>reason for that is simple - libc is linked into virtually every package, >>while I can't remember a single major release when version number for >>libc has not been bumped. > > > It is an issue for people that have binaries releases they don't have > source for. We claim to have binary compatibiltiy, when in fact we > don't really. It mostly works most of the time. > > People do complain when this doesn't work. I've spent a lot of time > in the past tracking down why programs randomly core dumped after > upgrading one minor part of the system, and this was a leading cause > after we changed the size of FILE. It caused me a lot of pain. > > Warner Yeah, well, that was your karmic punishment for touching the internals of FILE. Serves you right! Scott