Re: Bug#183564: Acknowledgement (limewire: Can't get limewire to go with libc 2.3.1)
From: Cardenas <email@example.com>
>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):
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
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 firstname.lastname@example.org
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:
__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
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.