5 ms·
> Aren't go programs statically linked? Not by default. You have to set CGO_ENABLED=0 to statically link libc.
by agnivade 9y ago
> Aren't go programs statically linked?
Not by default. You have to set CGO_ENABLED=0 to statically link libc.
- pmarin 9y agoDo native Go programs use libc?
- folago 9y agoI am pretty sure they don't.
- aleksi 9y agoFor a few things like system DNS resolver in net package (can be switched to the pure Go version with compile-time or run-time switch) and getting user's home directory in os/user package.
- sebcat 9y agoTo expand on this: $ cat foo.go package main import ( "fmt" ) func main() { fmt.Println("Hello") } $ go build foo.go $ file foo foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped compared to: $ cat bar.go package main import ( "os/user" "fmt" ) func main() { u, err := user.Current() fmt.Println(u, err) } $ go build bar.go $ file bar bar: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
- ptman 9y agoYou can usually build fully static by doing CGO_ENABLED=0 go build even when using os/user or net/
- sebcat 9y agoAt a computer with go1.4.2 freebsd/amd64 ATM (earlier was go1.8.1 linux/amd64 IIRC) and the above os/user example results in a dynamically linked ELF when built with CGO_ENABLED set to 0.
- agnivade 9y agoNope.
- arghwhat 9y agoWell, Go code is statically linked, but the runtime may try to dynamically load libc for DNS resolving. Use of cgo of course drastically change everything.
- pjmlp 9y agoBy default, nowadays the toolchain also supports generating dynamic libraries.