Trouble compiling dll that accesses another dll.

Question

So, I have an interesting issue. I am working with a proprietary set of dlls that I ,obviously, don't have the source for. The goal is to write an intermediate dll that groups together a large series of funnction calls from the proprietary dlls. The problem I am having, when compiling with g++, is that I get errors for the original dlls along the lines of: cannot export libname_NULL_THUNK_DATA. Symbol not found.

If I add a main and just compile to an executable everything works as expected. I'm using mingw for compilation. Thanks for any help.

In response to the first reply: Either I'm confused about what you're saying or I didn't word my question very well. I'm not explicitly trying to export anything from my wrapper I am just calling functions from their dlls. The problem is that I get errors that it can't export these specific symbols from the dll to my wrapper. The issue is that I'm not even entirely sure what these _NULL_THUNK_DATA symbols are for. I did a search and read somewhere that they shouldn't be exported because they're internal symbols that windows uses. I have tried using the --exclude-symbols directive to the linker but it didn't seem to do anything. I apologize if I'm completely misunderstanding what you're trying to say.

So, I think my issue was related to this. When just compiling a standard executable that uses a dll I was able to include the headers and directly call the functions for example:

#include :3rdparty.h
int main(){
  dostuff(); // a function in the 3rdparty.dll
}

this would compile and run fine. I just needed to link the libraries in the g++ command. When linking with the -shared flag I would get these errors (with main removed of course). I think it has something to do with the fact that by default g++ attempts to import all symbols from the dll. What I didn't understand is why this happens in the dll vs in an executable. I will try doing it using GetProcAddress(). Thank you!

Answer 1

"Compiling" tells me that you're approaching this from the wrong end. Your DLL should not export its own wrapper functions, but directly refer to exports from other DLLs.

E.g. in a Windows Kernel32.DEF file, the following forward exists:

   EXPORTS
   ...
   HeapAlloc = NTDLL.RtlAllocHeap

There's no code for the HeapAlloc function.

Answer 2

it should be as easy as you think it should be.

eg: your dll code needs:

void doStuff()
{
  3rdparty.login();
  3rdparty.dostuff();
  3rdparty.logoff();
};

so far - so good, you've included the right headers .... (if you have them, if you don't then you need to import the library using LoadLibrary(), then create a function pointer to each exported dll entrypoint using GetProcAddress() and then call that function pointer)

You then link with the 3rd party lib and that's it. Occasionally you will have to wrap the definitions with 'extern "C"' in order to get the linkage name mangling correct.

As you say you're using g++, you can't be getting confused with __declspec(dllimport) which is a MS VC extension.