Date: Fri, 18 Mar 2005 09:21:44 -0700 (MST) From: Warner Losh <imp@bsdimp.com> To: scottl@samsco.org Cc: das@FreeBSD.org Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h Message-ID: <20050318.092144.41681517.imp@bsdimp.com> In-Reply-To: <423A8A51.1070209@samsco.org> References: <423A86D9.5030504@portaone.com> <20050318.005008.71126625.imp@bsdimp.com> <423A8A51.1070209@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Scott Long <scottl@samsco.org> Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h Date: Fri, 18 Mar 2005 00:59:13 -0700 > Warner Losh wrote: > > From: Maxim Sobolev <sobomax@portaone.com> > > 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, > > It's because you are proposing something that is impossible to achieve > in real life. We could to the 'or' part of my proposal: bump everything. Right now we don't have binary compatibility for anything but the most trivial of cases. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050318.092144.41681517.imp>