4 ms·
I assume you knew this and were just making a point, but: OP is using the term "fat binary" in a totally different and incompatible way to how your wikipedia l
by Lazare 9y ago
I assume you knew this and were just making a point, but: OP is using the term "fat binary" in a totally different and incompatible way to how your wikipedia link defines it.
> every compiled language has that. It is not exclusive to Go.
I don't think the article claimed it was. But it is a lot harder with C than Golang for various technical reasons, and it's much, much harder still with most scripting languages.
- pjmlp 9y agoIt is super easy to do static binaries with C, I was already doing it in 1992, the first time I actually used C on my life. It only hard if one happens to mix glibc, a specific implementation of the ANSI C standard library, with any implementation of it.
- IshKebab 9y agoHahaha that is soooo wrong. You might think you make a static binary with C by passing -static but trust me you do not. I believe it is still actually impossible to link with glibc statically. It's only been possible to do a static binary on Linux since Musl was written and that was not in 1992. In the 2000's there was an attempt to make true static binaries possible on Linux (think it was called Autopackage) but they eventually gave up due to the effort required. The story on Windows is much better of course, but even there making a proper dependency-free (as much as possible) binary is much easier with Go than any other language. It's possible in Go because they don't depend on the C standard library and wrote their own linker.
- tedunangst 9y agoPretty sure pjmlp knows how hard life is with glibc. Possibly even knows a bit about other systems that aren't linux.
- rkeene2 9y agoIt is not impossible to link glibc statically, and in older versions of libc this did occur. However, the Linux community at the time decided that the tradeoff of disallowing the system NSS to be modular was too great -- Go developers disregard this and don't believe anyone does anything other than the defaults. Even still, it's possible to compile glibc such that those NSS modules are statically linkable. See here for further information: https://stackoverflow.com/questions/3430400/linux-static-linking-is-dead https://stackoverflow.com/questions/3430400/linux-static-lin... However, in 1992 it was entirely possible to statically link an application to libc4 and have it have no run-time dependencies other than the kernel ABI.
- justincormack 9y agoIt is now with Musl libc
- dullgiulio 9y agoGo doesn't disregard anything. It tried to parse NSS configuration, if there is no Go implementation available for the user conf it parsed, it falls back to glibc.
- rkeene2 9y agoOnly if you use "cgo", otherwise it doesn't have access to the run-time linker.
- dullgiulio 9y agoNo, by default.
- deleted 9y ago[deleted]
- pmoriarty 9y agoNot only was it possible to do static linking back in those days, it was easy and it was common. The glibc nss breakage only came later. I'm still unclear why it hasn't been fixed to once again allow easy static linking after all these years.
- pjmlp 9y agoIn 1992, we were using Xenix, Aix, HP-UX, Tru64, SGI, Solaris, DG/UX, MS-DOS, AmigaOS, Atari, OS/2.... All of them allowed for static linking, and only a few supported dynamic linking. Regarding Linux, the very first version to properly support dynamic linking was kernel 1.0.9, which introduced ELF support. Slackware 2.0 was one of the first distributions supporting it. Before that, binutils had a set of patching tools to make dynamic loading work in the a.out format. GNU/Linux is just one OS among many supported by C compilers.