RE: getting symbols from dynamic modules

["Freddie Unpenstein" <fredderic excite com>]

Yeah yeah...  I'm running a little behind.  Nothing unusual there.  ;)


On Mon 09/18, Tor Lillqvist < tml iki fi > wrote:
> Felix Kater writes:
> > g_module_* is a great thing -- I just wonder if there is a way
> > to not create function pointers for each single function I need
> > but just import all of them at once?
> Define a "suite" struct containing all the function pointers for
> your module, and then export just one function that returns a
> pointer to such a struct? Please have in the struct as its first
> member an int with the size of the struct, for the version of the
> module in question. When adding function pointers to your struct,
> add them to the end, keeping the previous fields intact. You *will*
> be glad later when you have different versions of your module and
> different versions of client apps deployed in the wild that you did
> that ;)

Iterating the library for symbols would be nice, though I'm assuming it comes with complications since it's 
not often done.  eg. You still need to specify the location into which to store those symbol locations.


I've seen the exported struct of functions done quite effectively, but altering the set of functions in the 
API at a latter date becomes a problem.  You end up with gaps in the list, and it gets annoying calling 
functions via the struct so you end up with a matching bunch of #define's or even wrapper functions.  
Although, I suppose it does mean that you don't actually need to export any symbols, except the initialiser 
function.  Which might actually have its own benefits.

On the other hand, if the API is prone to evolution, such as in the early stages, the practice of grabbing a 
symbol at a time could be beneficial, so long as you're only adding and removing functions.  To make life a 
little easier, you could well have a struct describing the name of the function you want, and where to shove 
its function pointer.  You can then run an array of such structs with a small function, filling in the 
function pointers as it goes along (and maybe target any it can't find at a "symbol not found" abort 
function).

Finally, even if you can't get the linker to do the work for you, you could probably get the compiler or some 
other tool to export a list of symbols, and build a header with the array of symbols and pointer storage 
variables for you.  I've used such techniques to build source file version number dump includes for debugging 
use.


Fredderic

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!