[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
> 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
> 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.
More information about the Java