jamiehale
06-06-2003, 10:42 AM
I've written a small scripting language for my geeky hobbies TableScript (http://www.sourceforge.net/projects/tablescript) and I'm trying to add dynamic libraries for user-defined add-in functions. Now I've only done of bit of dynamic libraries in Linux before, but I thought I understood the concept from years of win32 programming...
Anyways, I have a main body of code that implements a series of objects (including things like a symbol table). If a user script imports a dynamic library, I open it with dlopen(), call dlsym() to get the entry point (defined with extern "C"), and call into it with a pointer to the symbol table in the main executable. The libraries are compiled with access to all the definitions of the main body of code (including the symbol table), and so when the entry point calls a symbol table method to add a symbol, it happily compiles.
However, at runtime, it shuts down because of an apparently unknown symbol. It can't find a definition of the symbol table method that's being called.
I've used nm, and my executable definitely defines the method in question in the text segment, and the library definitely requires the method - in each case the mangled names are identical.
I should also note that when the symbol table reference is removed from the library code, it still fails because some other symbols aren't defined - the symbol table was just an example.
1) I'm using namespaces in my main code. Is there a problem with using shared symbols from within a dynamic library?
2) Can anyone think of anything that would be causing this?
I know what I want to do is possible - I've read through the Python code that handles it. I have no doubt it's done in many millions of other apps. Clearly I'm just missing something...
Anyways, I have a main body of code that implements a series of objects (including things like a symbol table). If a user script imports a dynamic library, I open it with dlopen(), call dlsym() to get the entry point (defined with extern "C"), and call into it with a pointer to the symbol table in the main executable. The libraries are compiled with access to all the definitions of the main body of code (including the symbol table), and so when the entry point calls a symbol table method to add a symbol, it happily compiles.
However, at runtime, it shuts down because of an apparently unknown symbol. It can't find a definition of the symbol table method that's being called.
I've used nm, and my executable definitely defines the method in question in the text segment, and the library definitely requires the method - in each case the mangled names are identical.
I should also note that when the symbol table reference is removed from the library code, it still fails because some other symbols aren't defined - the symbol table was just an example.
1) I'm using namespaces in my main code. Is there a problem with using shared symbols from within a dynamic library?
2) Can anyone think of anything that would be causing this?
I know what I want to do is possible - I've read through the Python code that handles it. I have no doubt it's done in many millions of other apps. Clearly I'm just missing something...