Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Oct 2003 22:38:29 -0600
From:      Scott Long <scottl@freebsd.org>
To:        Peter Wemm <peter@wemm.org>
Cc:        kris@obsecurity.org
Subject:   Re: __fpclassifyd problem
Message-ID:  <3F975B45.6010504@freebsd.org>
In-Reply-To: <20031023041544.068CD2A7EA@canning.wemm.org>
References:  <20031023041544.068CD2A7EA@canning.wemm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote:
> 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.
> 

This sounds like a good plan, though it should be noted that statically 
linking the jvm executable will reder it useless since it won't be able
to dl_open any of the essential JNI modules.


Scott



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