I’m trying to write a cross-platform program in c++ that will load certain modules (shared libraries) at runtime. To do this I’m using the ClassLoader from Poco C++ Libraries. I’ve written a compiling chain using autoconf, automake and libtool. This shouldn’t be any problem in a Linux environment, but the problem occurs in Windows. I’m using MinGW and MSYS when compiling to be able to make use of my Makefiles. ClassLoader uses the Windows-specific LoadLibrary() function to load the modules, which means I have to compile them as DLLs.
The class that I compile to a library inherits another class within the main application. Then when I try to run make, it complains a lot about undefined reference and refuses to build a shared library. I guess this is because of the name mangling. Or is it because I can’t inherit a class outside of the library? (That class is not included in the sources for the library, but the header file is found)
I’m not really sure how much trouble it’s going to bring that I insist on compiling under MinGW + MSYS but still make use of LoadLibrary(). Anyone with experience of this?
Under Windows, a DLL must have all of it’s symbols resolved when it’s built. Under Unixes, you can leave things unresolved until load-time, and this behavior is currently incorprated into your design.
To change that, you will probably have to break out the base class in the main application (and everything else that the DLL depends on) into it’s own DLL. That way, when you link your library that subclasses, it can link to the new DLL and fully resolve it’s symbols.
The catch is, you have to be able to build this new DLL with all of it’s symbols resolved.