cvs commit: src/lib/msun/i387 fenv.c fenv.h

[Warner Losh]

From: Scott Long <scottl at samsco.org>
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 <sobomax at 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.

Yes.  That's the situation that leads to mass core dumps and requires
that one rebuild everything.

Warner