[Qt-interest] dll problem

[Evan Teran]

There is actually something that does exactly what I want!

Unfortunately I found it after completely redesigning my plugin API so
that the plugins get a structure with of the functions they might care
about in an init function.

Anyway, on windows you *can* have a dll use symbols found in the .exe.
In fact, I discovered this after noticing another application which did
exactly what I had in mind :).

All you have to do is have to do is this:

* mark the functions you want the plugins to have access to with:
"__declspec(dllexport)"
* after compilation run dumpbin on your executable to get its exports
(since these tools work with a C style naming convention, you need to
include any name mangling found here).
* use dumpbins output to produce a .def file for your app
* use "lib /def:app.def" to create an "app.lib"
* in the plugin include the prototype of the function you want to access
 adding the "__declspec(dllimport)" to the declaration.
* link your plugins to app.lib

It sounds much more complicated than it actually is since all but the
last step are done once per revision of your API (and compiler version
due to ABI issues).

I've done some basic tests and it all seems to work perfectly. The
plugins properly resolve the symbols which are provided by the plugin.

The main reason I am prefering this is that there are several "utility"
classes which most plugins use. So in the beginning I placed these in my
main apps sources and the plugins just used them. Now with the new
system because these classes need function definitions, I have to have a
"core library" which all plugins link to. I can either make it static
which makes the install just as simple as before but bloats the binary.
Or I have have it shared and have an even more complicated dependancy
tree with an extra library that has to be installed. If having the main
.exe provide these classes is workable, it is simpler.

Also, if the main app can export symbols, then that means I only have to
update 1 place to change my API, not several (as I do now with my new
plugin system).

I'm going to try to automate the process of having app.lib created and
see how it goes. If all goes well, I'll post my results to the list in
case anyone else was interested in this.

Evan

Oliver.Knoll at comit.ch wrote:
> Evan Teran wrote on Monday, December 08, 2008 9:15 PM:
> 
>> Actually, my problem isn't lack of compilation. It's runtime crashes
>> that don't occur on my linux builds.
>>
>> I actually need to do the opposite of your suggestion to, because
>> some of my plugins use objects which are provided by my core
>> application.
> 
> That's "broken by design", also on Linux (in fact, this broken design has nothing to do with any OS, is a "platform-independent broken-by-design" :)
> 
> A plugin mustn't access symbols from the main application (executable), because an executable is - guess what - not a shared library!
> 
> So what you really need is a design with a clean dependency tree (no mutual dependencies!).
> 
> As already suggested several times you'd put the main functionallity of your application into a DLL/shared object and *export* the symbols you need in the above layers (plugins or other application libraries): for Windows google for (__declspec dllimport/dllexport), read the MSDN and/or create a sample DLL within Visual Studio. For reference you could also have a look at http://www.pointshop3d.com. It is based on Qt 2.x and I wrote a "plugin loader" myself (which basically did what QPluginLoader
> /QLibrary do nowadays) - but nevertheless you'll quickly see the DLL dependencies.
> 
> The main application then merely consists of a simple main() function which instantiates the QApplication object and pulls in all the application DLLs
> 
>> If i do have the noundef stuff in there (i ran into an
>> issue where ubuntu was adding it to the defaul flags on lib builds).
>> Then I get linker errors on Linux.
> 
> As expected - you can't export symbols/functions from an executable!
> 
>> Which isn't what I want :(.
> 
> Right ;)
> 
>> Likewise on windows builds I have to add /FORCE to the compiler flags
>> for plugins to let the linker not care about missing symbols since
>> they will be provided by the main app.
> 
> Broken by design, see above.
> 
> Cheers, Oliver