This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: [ATTACHEMENT TO:] BUG REPORT. Loading native-libs dynamicallyend up with cast-error...
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Anthony Green <green at redhat dot com>
- Cc: Clemens Eisserer <Linuxhippy at web dot de>, <java at gcc dot gnu dot org>
- Date: Fri, 29 Nov 2002 00:02:08 -0500 (EST)
- Subject: Re: [ATTACHEMENT TO:] BUG REPORT. Loading native-libs dynamicallyend up with cast-error...
On 26 Nov 2002, Anthony Green wrote:
> What I don't understand is that I had to compile _all_ of the code with
> -fpic or -fPIC in order to work -- even Loader.o and bi.o which don't
> end up in a shared library. The symptom of the failure is a
> ClassNotFound exception. I modified the test code to print a stack
> trace, but it just hangs instead of printing.
>
> Does anybody have any insight into this?
>From dlopen(3):
External references in the library are resolved using the
libraries in that library's dependency list and any other
libraries previously opened with the RTLD_GLOBAL flag. If
the executable was linked with the flag "-rdynamic", then
the global symbols in the executable will also be used to
resolve references in a dynamically loaded library.
In this case interface bi is undefined in lib-bte.so and defined in the
program executable, so it fails to resolve without -rdynamic:
[jsturm@saturn tmp]$ make
gcj -O2 -c -o Loader.o Loader.java
gcj -O2 -c -o bi.o bi.java
gcj -O2 -c -o bte.o bte.java
gcj -O2 -fPIC -shared -o lib-bte.so bte.o
gcj -O2 -rdynamic --main=Loader -o tes bi.o Loader.o
[jsturm@saturn tmp]$ ./tes
Hi!
Note this flag is passed to the linker as `--export-dynamic'.
Jeff