Re: Bug#183564: Acknowledgement (limewire: Can't get limewire to go with libc 2.3.1)

[tim@fungible.com (Tim Freeman)]

From: Cardenas <mbc@debian.org>
>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                                                  tim@fungible.com
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.