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

[Anthony Green]

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