From: Cardenas <[EMAIL PROTECTED]> >I can update the dependency to use java 1.4, but its probably the case >that java 1.4 was compiled with gcc 3.2 and 1.3 wasn't.
I think that updating the dependency to use java 1.4 is a good idea, unless there's reasonable expectation to get a java 1.3 compiled with gcc 3.2 someday. >Can someone on the glibc team take a look at this and see if its an >upstream bug in glibc? > >Apparently, the symbol __libc_recvfrom had the version GLIBC_2.0 in >glibc 2.2.5 and in glibc 2.3.1 it has the version GLIBC_PRIVATE. It could easily be a known bug. It resembles the problem described here (search for __clz_tab): http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200303/msg00006.html Since Java isn't a Debian package, I don't know if I've already done all that it makes sense to do to report it. I visited http://www.blackdown.org/cgi-bin/jdk and reported it there. That bug reporting system has about ~2000 unaddressed bugs, so they'll probably ignore this one too. To save people a few mouseclicks, here's the report I gave to the blackdown people at the latter URL above. It includes a diagnosis. If there's an easy workaround that makes glibc more compatible, it might be worth throwing in. -- Tim Freeman [EMAIL PROTECTED] Which is worse: ignorance or apathy? Who knows? Who cares? GPG public key fingerprint ECDF 46F8 3B80 BB9E 575D 7180 76DF FE00 34B1 5C78 I'm trying to use an application that needs J2SE_PREEMPTCLOSE set. The application is LimeWire; I don't have the source for it. Search /usr/lib/j2se/1.3/bin/.java_wrapper for "4344135" to see what J2SE_PREEMPTCLOSE is about. In .java_wrapper, setting J2SE_PREEMPTCLOSE puts libpreemptive_close.so on the LD_PRELOAD path before the real java interpreter is run. The application crashes with the message /usr/lib/j2se/1.3/bin/i386/native_threads/java: relocation error: /usr/lib/j2se/1.3/jre/lib/i386/libpreemptive_close.so: symbol __libc_recvfrom, version GLIBC_2.0 not defined in file libc.so.6 with link time reference The problem is that /usr/lib/j2se/1.3/jre/lib/i386/libpreemptive_close.so references the symbol __libc_recvfrom from libc6. This can be confirmed by giving the command objdump --dynamic-reloc /usr/lib/j2se/1.3/jre/lib/i386/libpreemptive_close.so | grep recvfrom and observing the output 0000be9c R_386_JUMP_SLOT __libc_recvfrom glibc6 2.3.1 has this symbol, but it is private. This can be confirmed by giving the command objdump --dynamic-syms /lib/libc.so.6 | grep __libc_recvfrom and observing the output 000c3f70 g DF .text 00000039 GLIBC_PRIVATE __libc_recvfrom __libc_recvfrom is not private in the previous glibc6, version 2.2.5. To verify, get libc-2.2.5.so from Debian woody and give the command objdump --dynamic-syms libc-2.2.5.so | grep __libc_recvfrom and observe the output 000cf3c0 g DF .text 0000003a GLIBC_2.0 __libc_recvfrom Note how this has "GLIBC2.0" where the output generated from libc 2.3.1 has "GLIBC_PRIVATE". I belive that right now, you couldn't recompile libpreemptive_close.so if you were running libc 2.3.1. Also, Java programs that need J2SE_PREEMPTCLOSE will stop working for lots of people once libc 2.3.1 becomes more commonly used. There is an exported and documented symbol "recvfrom" that might be useful in crafting a more stable substitute for using __libc_recvfrom. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
