Date: Sun, 19 Oct 2003 15:13:41 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Scott Long <scottl@freebsd.org> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: __fpclassifyd problem Message-ID: <20031019221341.GA32851@troutmask.apl.washington.edu> In-Reply-To: <3F92FC99.8010802@freebsd.org> References: <3F92E129.10307@veidit.net> <20031019204629.GC49466@rot13.obsecurity.org> <3F92FC99.8010802@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 19, 2003 at 03:05:29PM -0600, Scott Long wrote: > Kris Kennaway wrote: > > > >This symbol is defined in libc.so.5. One way you can see this problem > >is if you are running a 4.x binary that links to libm.so.2 on a 5.x > >system, because libm has the same version number in 5.x but is not > >binary compatible. So the 4.x binary links to libc.so.4 and > >libm.so.2, and the latter is actually a 5.x library that expects to > >have __fpclassifyd resolved by linking with libc.so.5. Is it the case > >on your system that you have old 4.x binaries installed? > > > >Kris > > 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? > I sent in an email *along time ago* about this type of problem. See the fallout due to revision 1.24 of lib/libc/stdio/findfp.c. IMHO, all shared libraries versions should have been bumped in going from 4.x to 5.0. -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031019221341.GA32851>