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 11:05:19 +0200
> 
> 
>>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.
> 
> 
> It is an issue for people that have binaries releases they don't have
> source for.  We claim to have binary compatibiltiy, when in fact we
> don't really.  It mostly works most of the time.
> 
> People do complain when this doesn't work.  I've spent a lot of time
> in the past tracking down why programs randomly core dumped after
> upgrading one minor part of the system, and this was a leading cause
> after we changed the size of FILE.  It caused me a lot of pain.
> 
> Warner

Yeah, well, that was your karmic punishment for touching the internals 
of FILE.  Serves you right!

Scott