Hacker News Reader

Comment by TazeTSchnitzel | Hacker News Reader

You can do the same thing with any compiled language, but I suppose that's a feature of Go since it's a compiled language.

View on HN

With other languages such as C/C++ if you link a library into your program statically, that library may dynamically load other dependencies. In Go, all dependencies have to be statically compiled into that package.

Rob Pike made a good point about this in one of the Go talks [1] (I think it was the "Meet the Go team" talk) when they were talking about package management and the static linking, and how in C++ you could get massive chains of useless includes (I think is came out of a question on the speed of the Go compiler). His reasoning was that all the code you need to compile a package should be in the one package binary. You shouldn't need to worry about having other 3rd-party packages that your dependency depends on installed on the target system.

[1] http://blog.golang.org/2012/07/go-videos-from-google-io-2012...

> In Go, all dependencies have to be statically compiled into that package.

This is not true. If you make use of cgo, the dependencies are linked dynamically.

Using cgo is an exception rather than the rule, and when Rob talks about package dependencies he means any file required for building that package, not only the shared objects. This includes C/C++ header files. Even with cgo, to use a package that uses cgo you only need that package archive, you need not care about what files that created that package.

Like in every other compiled language that has modules.

Yes, you are right. I was referring to pure Go packages.

You can do the same thing with any compiled language

This is not necessarily true. Remember the DLL hell? Go does not support dynamic linking at all (some say this is a disadvantage), so you are forced to produce a single self-contained binary.

DLL hell only happens if you use dynamic linking. Static linking is always an option. (actually, is it? I don't tend to use a lot of libraries, how much stuff that isn't part of the OS can you not statically link?)

I belive you need to also provide re-linking mechanisms for your customers if you statically link something licensed under LGPL.

DLL hell happened (in Windows) because you had to dynamically link against system libraries which could change in incompatible ways making your code fragile.

Depending on the nature of the development toolset, you may not be able to avoid DLL hell. E.g. you may not have the right to build the library into your code and/or the toolset may force you to link against external code libraries.

The original goal of Microsoft's DLL strategy was to save disk space (and presumably memory) but the end result was a compatibility nightmare. Retrospectively, it seems to have been both a bad technical decision (disk space turned out to be a bad thing to trade against other considerations) and badly implemented (too many DLLs went live and then broke backwards compatibility in updates). It seems like other companies managed to allow dynamic linking without creating so much fragility.

It's a great idea and still is. Linux does pretty much the same thing.

It actually broke because they didn't allow multiple versions and windows linked to the latest version at runtime.

They fixed all this with WinSXS which allows a PE file to specify a manifest i.e. a list of required versions of DLLs to load. This is all neatly explained here:

http://msdn.microsoft.com/en-us/library/aa376307.aspx

It would be more accurate to say dll hell happened because vendors decided to install their 3rd party dependencies in the windows directory. There are not as many problems with actual Microsoft dlls.

> Static linking is always an option.

Not if you use C and glibc (most common combination of them all, most software requires glibc). Even if you compile glibc statically in your program (not an option by default at least in Ubuntu), glibc itself will load more shared objects at runtime.

Oh, huh, I didn't know about that.

I've had very positive experiences with statically linking against musl[1], As long as your code and the required libraries don't use dlopen() tricks (e.g. as glib GIO does), you can quite reliably create a single statically linked binary for your program. Admittedly, this isn't as easy to setup as Go is.

[1] http://www.etalabs.net/musl/

You can statically link if you also compile a static glibc with modules disabled. But it's a pita and you can still have kernel compat problems.

Reply on news.ycombinator.com