/opt/compaq-jre-1.3.1/bin/alpha/native_threads/java: relocation error: /opt/compaq-jre-1.3.1/lib/alpha/libpreemptive_close.so: symbol __libc_accept, version GLIBC_2.0 not defined in file libc.so.6.1 with link time reference got this when trying to start limewire 4.6.0, which isn't supported for alpha probably, I know, but this seems like a bug not related to limewire, right? (limewire is the only relevant package I forced upon the system, the non-relevant packages are openafs-1.3.79 and the latest openinventor) Portage 2.0.51-r15 (default-alpha-2004.0, gcc-3.3.2, glibc-2.3.2-r12, 2.4.21-alpha-r17 alpha) ================================================================= System uname: 2.4.21-alpha-r17 alpha EV56 Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Aug 27 2004, 10:48:03)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r5 sys-devel/automake: 1.8.5-r1 sys-devel/binutils: 2.14.90.0.8-r1 sys-devel/libtool: 1.5.2-r7 virtual/os-headers: 2.4.23
alpha, please advise. this one is for you, since we can't reproduce it without access to such a nifty platform :(
I resolved the problem on my local system, after some googling. The resolution is a workaround (necessary as the Compaq JRE is binary only) that implements the obsolete __libc_accept function in a seperate shared library, and then LD_PRELOAD's this. I got this from https://www.redhat.com/archives/axp-list/2004-August/msg00019.html Create a source file with the following contents: #include <errno.h> #include <sys/syscall.h> #include <sys/types.h> #include <sys/wait.h> __pid_t __libc_wait (__WAIT_STATUS_DEFN stat_loc) { return __waitpid (WAIT_ANY, (int *) stat_loc, 0); } and call it libcwait.c. Then do gcc -O2 -shared -o libcwait.so libcwait.c. Put this binary in a safe place, and change the java wrapper-script so that it does export LD_PRELOAD=${path}/libcwait.so before loading the actual binary.
Hi First of all, and due to the actual situation of Compaq-java (upstream dead long time ago) i don't know if we are going to be able to solve this issue. Well, after the disclaimer, lets going to see what can we do: #1. Yes, we can reproduce the problem easily. I'm using compaq-jdk-1.3.1-r3 and limewire-4.8.1 . Limewire compiles just fine but, when you start it, it shows to you the error reported in the description of this bug about __libc_accept. #2. Problem with __libc_wait appeared on gentoo-alpha mailing list some time ago [1]. Stefaan, I found the same patch than you posted here, and seems to work fine. The problem here is that __libc_wait patch doesn't implement __libc_accept signal (at least for me). I had the same result with java-jdk patched this way. Stefaan, would you mind emerging limewire-4.8.1 (using your current compaq-jre patched), run it and post the results here? [1] http://marc.theaimsgroup.com/?t=112020017200001&r=1&w=2
Hmm... Maybe I'm being too stubborn, but anyway. I was indeed too quick to think this issue was fixed, there were other unresolved symbols. I looked them up in older glibc versions. The __libc_* versions seem to be copies of the versions without the prefixes (apart from some thing with weak aliases that I didn't completely understand). So I updated my libcwait.c file: #include <errno.h> #include <sys/syscall.h> #include <sys/types.h> #include <sys/wait.h> __pid_t __libc_wait (__WAIT_STATUS_DEFN stat_loc) { return __waitpid (WAIT_ANY, (int *) stat_loc, 0); } #include <sys/socket.h> int __libc_accept (int a1, struct sockaddr* a2, socklen_t* a3) { return accept (a1, a2, a3); } int __libc_recvfrom (int a1, void * a2, size_t a3, int a4, struct sockaddr * a5, socklen_t * a6) { return recvfrom (a1, a2, a3, a4, a5, a6); } int __libc_sendto (int a1, void * a2, size_t a3, int a4, struct sockaddr * a5, socklen_t a6) { return sendto (a1, a2, a3, a4, a5, a6); } int __libc_recv (int a1, void * a2, size_t a3, int a4) { return recv (a1, a2, a3, a4); } Now I enjoy the limewire 4.8.1 splash screen!! Hurray... almost The stdout/err messages I see are: Warning: Cannot find callback list in XtAddCallback Warning: Cannot find callback list in XtAddCallback log4j:WARN No appenders could be found for logger (com.limegroup.gnutella.gui.Initializer). log4j:WARN Please initialize the log4j system properly. I don't think the last two messages matter, as I get them on x86 as well, but the previous two might constitute a problem. Or maybe my approach extending libcwait.c was wrong. I'm clueless for the moment. Maybe you know what's going wrong now?
"Warning: Cannot find callback list in XtAddCallback" this is caused by a bad openmotif DEPEND in the ebuild: >=x11-libs/openmotif-2.1.30-r1 should be ~x11-libs/openmotif-2.1.30-r1 because compaq-{jre,jdk} seems to be statically linked to 2.1 openmotif libs. You can solve this problem with "emerge =x11-libs/openmotif-2.1.30-r9" (stable 2.1 openmotif). Don't worry, you aren't going to lose your 2.2 branch since the ebuilds use SLOT (2.1 and 2.2). After did this, i tried limewire. I recieve warnings from log4j, see the splash screen, but nothing happends after this. No errors, no program just the splash screen. I'll attach an strace log of limewire. Maybe libc_accept patch have something wrong. We could know if this is the problem if find another app with the same issue. Sorry but i can't help you with this patch because I lack of glibc-ninja-skills :( I'm planning on bumping revision of compaq-{jre,jdk} to solve this error with openmotif and the libcwait signal bug. I wait for the moment to see what can we do with this bug and another issues with xml support. Stefaan, thanks a lot for your help.
Created attachment 66515 [details] limewire strace log with __libc_accept patch
The current status of Java on Alpha doesn't let us handle Java bugs properly. We will revisit all Java related bugs once we find a good Java Virtual Machine for the Alpha Architecture.
