From owner-cvs-all@FreeBSD.ORG Fri Mar 18 16:32:37 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 B840F16A4CE; Fri, 18 Mar 2005 16:32:37 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB9C043D55; Fri, 18 Mar 2005 16:32:36 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2IGWTMA045309; Fri, 18 Mar 2005 11:32:29 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2IGWT1J045308; Fri, 18 Mar 2005 11:32:29 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Fri, 18 Mar 2005 11:32:29 -0500 From: David Schultz To: Warner Losh Message-ID: <20050318163229.GA43458@VARK.MIT.EDU> Mail-Followup-To: Warner Losh , sobomax@portaone.com, scottl@samsco.org, danfe@FreeBSD.ORG, src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <20050317.233645.74714466.imp@bsdimp.com> <20050318064521.GA42508@VARK.MIT.EDU> <423A86D9.5030504@portaone.com> <20050318.005008.71126625.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050318.005008.71126625.imp@bsdimp.com> cc: danfe@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: cvs-src@FreeBSD.ORG cc: scottl@samsco.org cc: sobomax@portaone.com cc: cvs-all@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:38 -0000 On Fri, Mar 18, 2005, 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.[*] In the case of libm, the API, but not the ABI, was broken by the removal of an obscure function. The idea behind matherr() is that an application overrides the stub in libm with its own definition of matherr(), and libm routines call into matherr() when an error occurred. Removing it shouldn't have broken the ABI because it's a callback that the application has to override in order to use. Why was it removed? The mechanism predates the IEEE 754 floating-point standard, and none of our libm routines ever did (or should) support it. So at best, matherr() could confuse applications that expected it to work. At worst, it led to a namespace conflict because it took an argument called 'struct exception', a name which some applications use and which math.h isn't supposed to define. However, I should point out that libm doesn't have a lot of internal state like libc does, so linking in libm.so.3 and libm.so.4 would probably not cause anything to blow up as long as the linker is happy. AFAIK, the linker only complains about duplicate symbols if LD_BIND_NOW is used.