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...
Hi!
I am really sorry for wasting yout and adam´s time. `m so stupid sorry
for all traffic I made.
GNU-Software is really great, thank you for your support!
I want to develop a mainstrem-dektop-tool for Linux-Users (I´m not sure
if I should take swt org java-gtk as gui) and I hope I can help GCJ to
more popularity.
Of cource I will tell the users how great gcj is! Thanks for wasting
yout tim for me, it works so great at all!
Thanks, thanks, thanks and good luck toward the future. Of course I´ll
visit the list as often as now, but I´m not shure if I can help
anybody, I´m not a gcj-professional ;-)
Thanks and good luck!
thx Linuxhippy
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