From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 Description of problem: java 1.2.2 runs on 32 bit redhat platforms but fails on AMD x86_64 systems. After the .java_wrapper realpath scripts are updated with the x86_64 machine name, the following error occurs: $ java -version Can't load library "/lsi/home/proj/GenTools/java/Linux/jdk1.2.2/jre/lib/i386/libjava.so", because /lsi/home/proj/GenTools/java/Linux/jdk1.2.2/jre/lib/i386/libjava.so: symbol __libc_wait, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Could not create the Java virtual machine. I note that readelf -a /bin/libc.so.6 typically produces this: ------------------------------------------------------------------------ Symbol table '.dynsym' contains 2242 entries: Num: Value Size Type Bind Vis Ndx Name ... 1792: 000a7620 163 FUNC GLOBAL DEFAULT 11 __libc_wait@@GLIBC_2.0 ------------------------------------------------------------------------ But it produces this on the 64 bit system: ------------------------------------------------------------------------ Symbol table '.symtab' contains 8703 entries: Num: Value Size Type Bind Vis Ndx Name ... 8250: 000aa700 163 FUNC GLOBAL DEFAULT 11 __libc_wait ------------------------------------------------------------------------ Note that the 64 bit system is missing the GLIBC_2.0 tag. Perhaps this is why java 1.2.2 is not running on the 64 bit system? If so, would relinking libc.so.6 WITH the GLIBC_2.0 tag solve this problem? Thanks for any help you can provide. Version-Release number of selected component (if applicable): glibc-2.3.2-95.6.src.rpm How reproducible: Always Steps to Reproduce: on a 64 bit system, 1. add x86_64 to the case statements in jre1.2.2/bin/.java_wrapper and jre1.2.2/bin/realpath 2. run "java -version" Actual Results: $ java -version Can't load library "/lsi/home/proj/GenTools/java/Linux/jdk1.2.2/jre/lib/i386/libjava.so", because /lsi/home/proj/GenTools/java/Linux/jdk1.2.2/jre/lib/i386/libjava.so: symbol __libc_wait, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Could not create the Java virtual machine. Expected Results: Should see something like this: $ java -version java version "1.2.2" Classic VM (build JDK-1.2.2_016, green threads, nojit) Additional info: $ uname -a Linux flyer 2.4.21-9.ELsmp #1 SMP Thu Jan 8 16:52:31 EST 2004 x86_64 x86_64 x86_64 GNU/Linux
__libc_wait is a glibc internal symbol that no app should ever use it. Some older buggy Java implementations use this, but they have since then been fixed AFAIK. There is zero difference between i?86 and x86_64 running 32-bit binaries in this regard though. The symbol is not exported from either glibc. Maybe you are using a hack preload library to work around that problem (such as ftp://people.redhat.com/drepper/libcwait.c) on i?86 and don't do this on x86_64?
locate -i libc | grep -i wait shows no libcwait on the system. Hmmm ... What would explain the following difference between systems? It seems to indicate to me that 1) the libjava.so is not the problem since it is the same on all systems, 2) the libc.so.6 is likely the problem since it differs between systems, and 3) the error message about the missing GLIBC_2.0 tag fits the data produced by readelf -a /lib/libc.so.6 | egrep -B 3 -A 3 '__libc_wait\>' ... i.e. I see that the "missing tag" is indeed missing. Oh, one more thing, 4) wait() is, of course, a system call. I am not sure how or why __libc_wait is in there, but I'd guess it's a stub to hook into the system call? ... also nm -g /lib/libc.so.6 | grep wait shows that __libc_wait *is* indeed an exported symbol. The typical libc.so.6 entry point shows the GLIBC_2.0 tag: 1792: 000a7620 163 FUNC GLOBAL DEFAULT 11 __libc_wait@@GLIBC_2.0 Whereas the x86_64 bit entry is: 8250: 000aa700 163 FUNC GLOBAL DEFAULT 11 __libc_wait Note the tag is missing. The error message complains about that missing tag.
Is your 32-bit system also RHEL3 or some other distribution? On RHEL3/i?86 __libc_wait@@GLIBC_2.0 definitely is not exported from libc.so.6, but you can use a hack like the libcwait.c to work around it if you can't upgrade Java to a less buggier one. mkdir -p /some/dir/{lib,lib64} gcc -O2 -shared -fpic -o /some/dir/lib/libcwait.so libcwait.c echo '' | gcc -O2 -shared -fpic -xc - -o /some/dir/lib64/libcwait.so export LD_LIBRARY_PATH=/some/dir/lib:/some/dir/lib64${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH} LD_PRELOAD=libcwait.so java args...
Hmmm ... the system I checked is Red Hat Linux release 7.2 (Enigma) It is the one with the GLIBC_2.0 tag. That's quite old. Unfortunately, businesses and engineering software often need to work with / on old systems. :-/
RHL7.2 made this *internal* symbol available. But it is an internal symbol as the leading underscore shows and the JVMs incorrectly used it. After the symbol has been removed those program stopped working. It's entirely the fault of the JVM authors and they have corrected their code in later released. You have two options: - use a more recent JVM - use the libcwait.c file referenced in comment #1. Compile it as a shared library and preload it with LD_PRELOAD to every JVM run. There is no bug in glibc. I'm closing the bug.