Daniel Eischen wrote:
On Mon, 20 Oct 2003, M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]> Scott Long <[EMAIL PROTECTED]> 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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
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
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
