views:

1213

answers:

3

I'm in the process of porting a large C++ application from Linux (gcc) to Windows (Visual C++ 2008) and am having linker issues with plugins. On Linux this wasn't an issue, as .so supports runtime symbol lookup, but dll does not seem to support this.

Some background information: The application (the host), which hosts a scripting environment, provides interfaces to plugins (shared libraries that are loaded at runtime by script API calls), allowing the host and the scripting API to be extended without recompiling the host application. On Linux this is just a matter of including the host application's headers in the plugin source, but on Windows I'm receiving linker errors. I'm not sure exactly what I need to link with for Visual C++ to resolve these symbols.

One of our dependencies (open source, LGPL) has preprocessor declarations that it uses to insert __declspec(dllexport) and __declspec(dllimport) into it's headers. Some prior research indicates that I may have to do this as well, but I'd like to be sure before I go modifying a whole bunch of core headers. (I was previously able to get this working on MinGW, but we've decided that supporting Visual Studio is a requirement for this sort of commercial project.)

My question, in a nutshell: How do I link runtime-loaded dlls against a host exe in Visual C++?

Edit: To clarify the problem with an example, I have a class in my host application, Object, which represents the base type of an object that may be accessed by a script. In my plugins I have a number of classes which extend Object to perform other functions, such as integrating networking support or new visual elements. This means that my dll must link with symbols in the host exe, and I am not sure how to do that.

+3  A: 

What do you mean by "runtime symbol lookup"? Do you mean dynamically loading libraries using dlopen and dlsym and so on? The equivalents in Windows are called LoadLibrary and GetProcAddress.

In windows, you don't export symbols from a executable. You should only export them from a dll. The right way to solve your problem is to rearchitect so that the exported symbols are in a dll that the executable and other plugin dlls can link against.

1800 INFORMATION
That's exactly it, and I am able to do that fine, but I can't figure out how to compile that dll against symbols defined in my host executable (See my recent edit)
Sean Edwards
You _can_ export symbols from an EXE; just use GetProcAddress(GetModuleHandle(NULL), "MyProc)) to pick them up.
Roger Lipscombe
...but the Windows loader won't do this automatically for you.
Roger Lipscombe
+1  A: 

You can't, easily. The windows loader isn't designed to export symbols out of an EXE and bind them to symbols in a DLL.

One pattern that I have seen is the DLL export a certain function that the EXE calls. It takes as a parameter a structure which contains addresses of functions in the EXE for the DLL to call.

Michael
+1  A: 

As 1800 INFORMATION says, don't do it like that. Move Object out of the executable and into a "third" DLL. Link the plugins and the executable against that.

Logan Capaldo