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

[Maxim Sobolev]

Scott Long wrote:
> 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.

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
> 
> 
>