Date: Fri, 18 Mar 2005 11:05:19 +0200 From: Maxim Sobolev <sobomax@portaone.com> To: Scott Long <scottl@samsco.org> Cc: Warner Losh <imp@bsdimp.com> Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h Message-ID: <423A99CF.7010302@portaone.com> In-Reply-To: <423A8DC5.5010006@samsco.org> References: <20050317.233645.74714466.imp@bsdimp.com> <20050318064521.GA42508@VARK.MIT.EDU> <423A86D9.5030504@portaone.com> <20050318.005008.71126625.imp@bsdimp.com> <423A8B51.3010609@portaone.com> <423A8DC5.5010006@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote: > Maxim Sobolev wrote: > >> 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, 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. -Maxim > > Unfortunately, we already tried the tactic of ignoring compatibility, > and it bit us in the rear with libm (and a number of other libraries). > Many people spent many months sorting that mess out, and I don't really > care to repeat that mistake. Warner is right that bumping libraries too > often and/or for the wrong reason will also cause problems, so a middle > ground has to be found. Keeping eternal backwards compatibility in the > source is unmanageble, however. > > Scott > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?423A99CF.7010302>