__fpclassifyd problem
Daniel Eischen
eischen at vigrid.com
Mon Oct 20 06:23:42 PDT 2003
On Mon, 20 Oct 2003, M. Warner Losh wrote:
> In message: <3F92FC99.8010802 at freebsd.org>
> Scott Long <scottl at freebsd.org> writes:
> : We need to resolve this before 5.2 in some fashion. It looks like the
> : easiest thing to do is bump libm. Is this advisable?
>
> The problem with bumping libm is that we also need, strictly speaking,
> to bump all libarires that depend on libm, and that can be very ugly.
> This moves the bump the major version from the trivial fix class to
> something that we have to think real hard about. In general one
> cannot bump the major version of 'base' libaries like this w/o careful
> thought and planning. While we've done that in the past with libc, I
> think we were wrong to do so in some classes of symbol tampering.
>
> Warner _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
> send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
If it's just __fpclassifyd(), can you just add a compatability
hack to libm so it works with both libc 4.0 and 5.x? You
can make __fpclassifyd a weak definition to the hack in libm.
I suppose you could also add __fpclassfyd() to libc 4.0.
--
Dan Eischen
More information about the freebsd-current
mailing list