Why isn't it easy to compile dlls inline?

Question

I was dinking with some c++ and I wonder why it's not simple to just inline dlls when you do a release build? Seems like it would be easier. Is this a relic from when disk space was at a premium and it just never changed?I'm trying to compile some code and it works, but I found I have to copy the dll to the working dir and I was just wondering why cmake or vs build doesn't just have a "fat binary" build... would make life easy. Not complaining, just wondering.

skydhash · Accepted Answer

What you're searching for is static linking. Also see https://en.wikipedia.org/wiki/Static_library. That's mostly what Go do. For libraries that are used throughout the system (standard libraries,...), it does not make sense for every software to have its own copy, so dynamic linking is kinda the norm. And sometimes license.

dataflow · Answer

To everyone suggesting static linking: I believe the question is why can't you inline the DLL itself into an executable. To which the answer is, you probably could, in theory. There's just no well-known tool for it, AFAIK, though there are lesser-known projects on online that do similar things, but I've never tried them on this particular task.

worewood · Answer

Seems an interesting question, I googled for it and found a StackOverflow discussion...Just.. Wow. The ignorance of people is shocking. Some guy even said that it's not possible because a DLL can contain an entry point which is called when the DLL is loaded and a static library has no such thing... well nothing prevents me from manually calling such entry point from my main function. At the end it's all executable code, and it's absolutely possible to relocate some addresses and repackage the code as a static library. It's just that no one with the knowledge had a need to do it.

sqrt_1 · Answer

If you are thinking about the C runtime on Windows, you can statically link those dlls into your program via compile time options.
There are valid reasons for dlls however. The main one being symbol name collision.
For example, you can use a dll that links to version 1 of a library, while using version 2 of the library yourself without having any name collisions.
Many years ago when I did Linux development this was a main gripe of using .so files - imported names could clash with the same global names in your program and you get random runtime behaviour.

petabyt · Answer

In GCC you have .a, which is a collection of .o files that can be linked to a binary. I think the Windows equivalent is .lib?