Bug 134160
Summary: | AMD x86_64: java 1.2.2 fails since system glibc __libc_wait missing GLIBC_2.0 tag | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Daniel Ortmann <dortmann31415> |
Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | drepper |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-01 06:18:56 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Daniel Ortmann
2004-09-29 20:49:40 UTC
__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. |