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: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: drepper
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-01 02:18:56 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Daniel Ortmann 2004-09-29 16:49:40 EDT
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
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

Thanks for any help you can provide.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
on a 64 bit system,
1. add x86_64 to the case statements in
jre1.2.2/bin/.java_wrapper and
2. run "java -version"


Actual Results:  $ java -version
Can't load library
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
Comment 1 Jakub Jelinek 2004-09-30 03:56:11 EDT
__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?
Comment 2 Daniel Ortmann 2004-09-30 11:07:48 EDT
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 
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 
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 
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. 
Comment 3 Jakub Jelinek 2004-09-30 12:35:54 EDT
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...
Comment 4 Daniel Ortmann 2004-09-30 14:52:56 EDT
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.  :-/ 
Comment 5 Ulrich Drepper 2004-10-01 02:18:56 EDT
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.