[qub] thoughts on dso's

[Stephan B. <st...@wa...>]

Rusty,

I was just browsing through ClassLoader.c++ (okay, it was because I'm
incredibly bored, but not tired enough to sleep), and came across some
comments of yours which were interesting (from
ClassLoader::loadClassInfo()):

----------
This probably needs to be RTLD_GLOBAL... if Foo is a base class 
of Bar, Foo either needs to be compiled into both of them (boo), 
Foo needs to be loaded first, RTLD_GLOBAL (the order is tough/ 
impossible? to enforce), or Bar needed to link with Foo (hard to 
remember to do).  Fuggly.  Most likely the easiest way people 
will be able to get this to work is to put all their loadable 
classes into a single dso... much easier than managing the 
runtime link dependencies of a bazillion objects.
----------

By coincidence, I had been thinking about that earlier. At einsurance
I'm just starting to work with building C/C++ dlls, and accessing them
from Java, and I'm looking forward to learning enough about it to where
I can get dll's loading from qub. As far as I understand, it's not
currently a limitation of libFun, but only the fact that I've been
statically linking everything. I just don't know enough about it at the
moment to deal with shared libs.

I had the same thoughts about dll's, too. Does each plugin/piece/etc
need to be in it's own .so file, with the same name as the object (or
libObjectName)? If we don't do it that way, how will we know where to
go look for objects? We can't just go loading every dll on the system
until we find that object.
Perhaps all qub dll's go in one dir (gameset.root/qub/lib?)? Perhaps we
just have one big so, and all plugins have to be built and linked into
it? Any new plugins would need their tree under the main lib's source
tree, so they could all be built/linked into one big lib.
Or perhaps we have users manually register dll's with QUB (perhaps used
in conjunction with auto-loading all libs in a certain dir)?

What're your thoughts?

----- Stephan Beal
http://www.wanderinghorse.net
http://qub.sourceforge.net
st...@wa...
ste...@ei...