4

I'm wondering if it's possible to combine multiple DLL's into 1. I'm currently working on a C++ project that is dependent on many dynamic link libraries,so would it be possible to combine them into 1 DLL file, and if so, how would I do that?

Greg Treleaven
  • 8,124
  • 7
  • 30
  • 30

3 Answers3

5

I do have the source code for these DLLs, yes.

Just combine all the source files from all the DLL projects into a single DLL project?

And if you have multiple *.def files (one for each project) then combine them into a single *.def file.

ChrisW
  • 54,973
  • 13
  • 116
  • 224
2

Realistically, no. In theory, if you wanted to badly enough you could do something like disassembling all of them, then re-assembling all the separate files into object files, then re-linking those object files into one big DLL. Getting this to actually work would usually be non-trivial though -- there are likely to be things like conflicting symbol names that would require considerable work to get around.

A rather cleaner possibility would be to package all the DLLs into a zip file (or whatever you prefer) and have a small program to unzip them to a temporary directory, run the main program, and then erase the DLLs from that directory. This has a few problems of its own though (e.g., leaving copies of the files if the machine crashes/loses power/whatever during a run).

Edit: Since you have the source code, using it to build all the code into a single DLL is much more reasonable. For the most part, it's just a matter of adding all the source files to a single project that creates one DLL as its output. You may (easily) run into some symbol conflicts. Given access to the source code, the obvious way to deal with this would be by putting things into namespaces.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
1

Its certainly not infeasible. The Dll format contains all the information you need to merge the code and data from multiple dlls into one, and rebase the resulting code.

this is not a standard feature of any toolchain I can think of though.

Chris Becke
  • 34,244
  • 12
  • 79
  • 148
  • In the general case this isn't possible really, you'll have a lot of duplicate symbols. Parts of the CRT (all of it if you link it statically) will be in both processes, possibly optimized so it's not exact copies either. – Blindy Aug 29 '10 at 18:29
  • 1
    That would be re-linking. There is no name-level operation required to glue two dlls together. all you would do is concatenate, or create duplicate (renamed) .text, .sdata etc sections (the names of these sections are not actually relevent). and then process the relocation table - adjusted for the new base address of the merged sections. symbol names don't enter into it (unless you are trying to fixup debugging info). – Chris Becke Aug 29 '10 at 18:50
  • You also have to clean up the Import Address Tables, if one of the combined DLLs depended on another. You can't depend on yourself. And that _is_ a name-level operation; you have to match imported and exported entries by scope (DLL) and symbol name. – MSalters Aug 30 '10 at 10:08
  • ooo. I admit I didn't consider cross dependencies. There still isnt a name collision though as the names resolve unambiguously to functions in the merged (or external) dlls. – Chris Becke Aug 30 '10 at 10:28
  • This is all moot though. The OP has the source and can (and should (MUST really))) just build a merged dll. – Chris Becke Aug 30 '10 at 10:28