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>