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

[David Schultz]

On Fri, Mar 18, 2005, 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.[*]

In the case of libm, the API, but not the ABI, was broken by the
removal of an obscure function.  The idea behind matherr() is that
an application overrides the stub in libm with its own definition
of matherr(), and libm routines call into matherr() when an error
occurred.  Removing it shouldn't have broken the ABI because it's
a callback that the application has to override in order to use.

Why was it removed?  The mechanism predates the IEEE 754
floating-point standard, and none of our libm routines ever did
(or should) support it.  So at best, matherr() could confuse
applications that expected it to work.  At worst, it led to a
namespace conflict because it took an argument called 'struct
exception', a name which some applications use and which math.h
isn't supposed to define.

However, I should point out that libm doesn't have a lot of
internal state like libc does, so linking in libm.so.3 and
libm.so.4 would probably not cause anything to blow up as long as
the linker is happy.  AFAIK, the linker only complains about
duplicate symbols if LD_BIND_NOW is used.