From owner-cvs-src@FreeBSD.ORG Fri Mar 18 16:24:31 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66CDE16A4DE; Fri, 18 Mar 2005 16:24:31 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B429B43D31; Fri, 18 Mar 2005 16:24:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j2IGNlE5048267; Fri, 18 Mar 2005 09:23:47 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 18 Mar 2005 09:23:47 -0700 (MST) Message-Id: <20050318.092347.71135021.imp@bsdimp.com> To: scottl@samsco.org From: Warner Losh In-Reply-To: <423A8DC5.5010006@samsco.org> References: <20050318.005008.71126625.imp@bsdimp.com> <423A8B51.3010609@portaone.com> <423A8DC5.5010006@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2005 16:24:31 -0000 From: Scott Long Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h Date: Fri, 18 Mar 2005 01:13:57 -0700 > 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. Yes. That's the situation that leads to mass core dumps and requires that one rebuild everything. Warner