Ask HN: Why isn't it easy to compile dlls inline? | Hacker News Reader

Ask HN: Why isn't it easy to compile dlls inline?

4 pointsh_tbob9 comments

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.

View on HN

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.

That said, it is orders of magnitude harder to switch a dependency than it should be.

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.

.NET supports "inlining" DLLs as you suggest, though it extracts bundled libraries to a temporary directory before execution when native libraries are involved.

https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

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.

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.

And the other reason for dlls for common system libraries, security. If a security bug is found in a dll that is shared amongst a lot of programs, that can be updated without having to recompile all the programs.

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?

In the case of static linking, yes; they even share a common file format:

  $ file /usr/lib64/libzstd.a vcpkg/installed/x64-windows*/lib/zstd.lib
  /usr/lib64/libzstd.a:                            current ar archive
  vcpkg/installed/x64-windows/lib/zstd.lib:        current ar archive
  vcpkg/installed/x64-windows-static/lib/zstd.lib: current ar archive

But note that one of these things is not like the others:

  $ ar t vcpkg/installed/x64-windows/lib/zstd.lib | wc -l
  189
  $ ar t vcpkg/installed/x64-windows/lib/zstd.lib | uniq
  zstd.dll

This is a Windows import library. It contains no code; linking to it results in an executable dynamically linked to zstd.dll (equivalent to GCC -lzstd without -static on a typical Linux system).

Note that the objdump command[1] from GNU binutils works on Windows .lib, .dll, and .exe files, if you want to know more about what they contain.

[1] https://sourceware.org/binutils/docs-2.42/binutils/objdump.h...

Reply on news.ycombinator.com