tags:

views:

164

answers:

2

Consider this situation:

I'm creating a DLL (let's call this dllA), which, in turn, calls functions in other DLLs (let's call these dllX, dllY and dllZ). If someone else wanted to use dllA, they'd need a copy of dllX, Y and Z as well.

Is there a way to build dllA such that the needed functions in dllX, Y and Z get linked into dllA? I don't know if this is the right terminology, but is this called "statically linking a DLL"?

I'm looking for a simple solution. I'd be happy with something crude that simply concatenates dllX, Y and Z and appends that to dllA somehow, if such a thing exists. But I have this bad feeling that there's no easy solution to this.

I'm on Windows, using VS.

Thanks!

+1  A: 

I don't believe you can. I haven't heard of it being done. If you have build access to your other DLLs then you can build them as static libraries and that will work as you want but there's a reason why they're called dynamic link libraries.

EDIT: Just found this thread.

Nick Bedford
+1  A: 

You can't statically link a DLL, only a LIB. DLLs are self contained and have static members and DllMain load/unload dependencies that means they cannot be split into containing functions and linked into a different executable.

You should create an installer that deploys all the appropriate dlls, as needed.

If you really think is that important and you cannot rely on your app installer you can create a wrapper that embeds the needed dlls (A, X, Y and Z) as resources and at runtime extracts them and write them to disk in the user profile temp folders, then loads the extracted dllA and defers all incoming function calls to the loaded dllA. Some of the sysinternals tools used similar techniques to extract x64 images of the application from the x86 image and relaunch themselves as 64bit processes w/o having to ship two separate exes.

Remus Rusanu