Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Oct 2003 21:15:44 -0700
From:      Peter Wemm <peter@wemm.org>
To:        deischen@freebsd.org
Cc:        kris@obsecurity.org
Subject:   Re: __fpclassifyd problem 
Message-ID:  <20031023041544.068CD2A7EA@canning.wemm.org>
In-Reply-To: <Pine.GSO.4.10.10310200918170.20170-100000@pcnet5.pcnet.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote:
> On Mon, 20 Oct 2003, M. Warner Losh wrote:
> 
> > In message: <3F92FC99.8010802@freebsd.org>
> >             Scott Long <scottl@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@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
> > send any mail to "freebsd-current-unsubscribe@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.

We tried this at usenix, but it still didn't work.  Obviously there is more
going on.

Before anybody goes and bumps libraries etc, it would be useful to know if
running a statically linked jvm will work on -current.  If that does, then
the next thing to try is using a complete exclusive set of 4.x libraries
and ld-elf.so.1 somewhere and running in a chroot environment.  The next
step is to use the 5.x ld-elf.so.1, but $LD_LIBRARY_PATH to search for and
find the 4.x libraries in preference to the 5.x ones.  And so on.  If it
still works at this point,  then try switching the unbumped libraries one
at a time until it breaks.

Bumping the library versions is only useful IF it actually solves the
problem.

Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031023041544.068CD2A7EA>