When I was doing the JAVA sometime ago I hit a similar problem. I was
directed to the fix below which solved the problem. YMMV if this is the
same but the symptoms are close.
[root@vmlnx001 /local]# more libfixframeinfo.c.1
/*
* Shared library to be preloaded in order to run programs
* compiled on a system with egcs-compiled glibc.
*
* Based on an idea from Martin Schulze <[EMAIL PROTECTED]> and
* confirmed by John Williams <[EMAIL PROTECTED]>.
*
* Compile with:
* gcc -shared -o libfixframeinfo.so libfixframeinfo.c
*
* Then preload with:
* export LD_PRELOAD=/foo/bar/libfixframeinfo.so
*/
/*
From the glibc 2.1 FAQ:
2.8. When I run an executable on one system which I compiled on
another, I get dynamic linker errors. Both systems have the
same
version of glibc installed. What's wrong?
{ZW} Glibc on one of these systems was compiled with gcc 2.7 or 2.8, the
other with egcs (any version). Egcs has functions in its internal
`libgcc.a' to support exception handling with C++. They are linked into
any program or dynamic library compiled with egcs, whether it needs them
or
not. Dynamic libraries then turn around and export those functions
again
unless special steps are taken to prevent them.
When you link your program, it resolves its references to the exception
functions to the ones exported accidentally by libc.so. That works fine
as
long as libc has those functions. On the other system, libc doesn't
have
those functions because it was compiled by gcc 2.8, and you get
undefined
symbol errors. The symbols in question are named things like
`__register_frame_info'.
For glibc 2.0, the workaround is to not compile libc with egcs. We've
also
incorporated a patch which should prevent the EH functions sneaking into
libc. It doesn't matter what compiler you use to compile your program.
For glibc 2.1, we've chosen to do it the other way around: libc.so
explicitly provides the EH functions. This is to prevent other shared
libraries from doing it.
{UD} Starting with glibc 2.1.1 you can compile glibc with gcc 2.8.1 or
newer since we have explicitly add references to the functions causing
the
problem. But you nevertheless should use EGCS for other reasons
(see question 1.2).
*/
__register_frame_info() {}
__deregister_frame_info() {}
__unregister_frame_info() {}
To: [EMAIL PROTECTED]
"T. E. Lombardi" cc: (bcc: Michael Short/Towers
Perrin)
<[EMAIL PROTECTED] Subject: java execution thwarted by
error in loading
du> shared libraries
Sent by: Linux on
390 Port
<[EMAIL PROTECTED]
IST.EDU>
05/31/2002 11:55
AM
Please respond to
Linux on 390 Port
I am having problems getting java to run in my VM (kernel 2.2.15)
I have installed the IBMJava2-s390-131 version without error but
when I actually try to use javac I receive the following error:
error in loading shared libraries:
/opt/IBMJava2-s390-131/bin/exe/javac:
symbol __register_frame_info, version GLIBC_2.0
not defined in file libc.so.6 with link time reference
I suspect that I have to upgrade GLIBC and possibly the kernel.
Is this correct and if so what references should I consult to
perform these tasks properly?
I am fairly new at this so any and all advice is greatly appreciated.
Tom Lombardi
