From owner-cvs-all@FreeBSD.ORG Fri Mar 18 07:51:15 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 1A50716A4CE; Fri, 18 Mar 2005 07:51:15 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7885043D54; Fri, 18 Mar 2005 07:51:14 +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 j2I7o8I1040018; Fri, 18 Mar 2005 00:50:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 18 Mar 2005 00:50:08 -0700 (MST) Message-Id: <20050318.005008.71126625.imp@bsdimp.com> To: sobomax@portaone.com From: Warner Losh In-Reply-To: <423A86D9.5030504@portaone.com> References: <20050317.233645.74714466.imp@bsdimp.com> <20050318064521.GA42508@VARK.MIT.EDU> <423A86D9.5030504@portaone.com> 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: scottl@samsco.org 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 07:51:15 -0000 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.[*] Warner [*] Please, let's not have the silly discussion we seem to have every 4 months about making libc.soemthing-other-than-major-here. All the times in the past, all the naive proposals were shown to have such bad flaws as to be unworkable...