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

Wed Nov 27 13:47:00 GMT 2002

On Wed, 2002年11月27日 at 12:48, Linuxhippy wrote:
> >tes: Loader.o bi.o lib-bte.so
> > $(GCJ) --main=Loader -o $@ bi.o Loader.o
> > 
> >
> This does mean, you linked bte to tes at compile-time, not at run-time.
> Its needed, that the compilier doesnt know the class bte at all, it is 
> only allowed to now its interface bi, which must be the same for all 
> "plugin"-classes i want to use.

The bte class is linked at runtime. Loader does a Class.forName("bte"),
which causes the runtime library to look around for an implementation of
bte. It finds one in lib-bte.so, thanks to the library naming scheme we
use. bte implements the bi interface, which can live in either tes or
lib-bte.so -- it just needs to be in one of those two places.
> What I want to do is to write an app, to parse the name of the class 
> that should loaded out of a config-file and the load the class whithout 
> knowing how the class is built.

That's fine. That's what your example does. We don't link bte into the
executable.
> Your executable already knows bte at compile-time because its into 
> libbte.so, thats not what I want to do ;-((

No, the tes program has no idea about bte. I'm not linking bte in at
tes' link time. It is found by name at runtime in a separate shared
library.
> Could you please try to compile it without bte linked in? I know I´m 
> nerving, but I cant belive that I´m to stupid (I´m really not very 
> intelligent *g*) to get this up`n`running.

Perhaps the Makefile is confusing because I made tes depend on
lib-bte.so in the Makefile. This was just to force the bulding of
lib-bte.so -- it's not actually linked into the program.
AG