I've been working with an open-source C++ program on Windows using MSYS2 and MinGW, and while it compiles correctly, I'm overwhelmed by the sheer number of DLLs I have to manage. Many of these are dependencies of other dependencies, and I'm not sure they are all necessary for the original program to work. I have a couple of ideas:
1) For dynamic linking, is there a way to only include the libraries that my program directly uses? I know that usually, if a library can't find its dependencies, it won't load, but is there a workaround?
2) With static linking, while the executable tends to be quite large, is there a way to selectively include only the blocks of code that my program needs? It's potentially feasible in theory, but are there any practical implementations of this for common OS and development tools? I'm also aware that licensing could complicate things, but I really just want to focus on the technical aspects. Sorry if my queries seem a bit muddled, I'm not a programming expert!
2 Answers
You're touching on linker optimizations. With link-time optimization (LTO), tools like GCC and Clang can help reduce the unused code that's linked, which can effectively cut down on unnecessary dependencies in your executable. It's a good starting point!
You might want to consider using a build system like CMake that can help automate dependency management. The issue you’re facing with DLLs is common because your executable includes a metadata table listing all dependencies. If the OS can’t find them, it simply won’t run. For static linking, compilers usually implement dead-code elimination, so you can indeed cut out the unneeded parts, but keep in mind it makes your file size bigger if you include everything else.

That’s true! In embedded systems, it’s common to handle dependencies manually or use containers since stability over long periods is essential. You really want to ensure everything is consistently available, which means sometimes you'd rather keep everything local to avoid potential issues with losing libraries.