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

[Scott Long]

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,

It's because you are proposing something that is impossible to achieve
in real life.

Scott