[ATTACHEMENT TO:] BUG REPORT. Loading native-libs dynamically end up with cast-error...

Sat Nov 30 07:53:00 GMT 2002

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
>>>>