Does Go depend on C runtime?

Question

I can't find info does golang depend on c runtime? If it's depend on it is it's statically compiled in go-binary to make Go-app work everywhere without dependences?

Here is topic about what C-runtime is

Answer 1

I think the accepted answer is correct, but a binary which imports the 'net' package usually depends on a c runtime even in go 1.10 and Unix.

Here is the example of the simple echo server:

package main

import (
        "io"
        "log"
        "net"
)

func main() {
        ln, err := net.Listen("tcp", ":8080")
        if err != nil {
                log.Fatal(err)
        }

        for {
                conn, err := ln.Accept()
                if err != nil {
                        log.Print(err)
                        continue
                }

                _, err = io.Copy(conn, conn) // blocked until the client closes the conn.
                if err != nil {
                        log.Print(err)
                        continue
                }

                if err = conn.Close(); err != nil {
                        log.Print(err)
                }
        }
}

Build it and check its dependencies:

$ go build ./libc_check.go
$ ldd ./libc_check
        linux-vdso.so.1 =>  (0x00007ffe34fc1000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc005d4e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc005984000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc005f6b000)

It is because 'the decision of how to run the resolver applies at run time, not build time' as the release note indicates.

To avoid this dependency, use the 'netgo' build tag like this:

$ go build -tags netgo ./libc_check.go
$ ldd ./libc_check
        not a dynamic executable

Answer 2

If you're talking about executable files provided by a Go compiler, then the answer is "yes or no—it depends":

In most cases, the resulting executable program does not depend on a C run-time library.

However, on some platforms under certain circumstances the C runtime library gets dynamically linked in. In particular, this was the case with Go versions < 1.5 on Linux when DNS resolution was used: the runtime depended on the platform's libc implementation to handle such resolution. In 1.5 this has been reworked.

Another possible case is (IIRC) Solaris which provides no stable way to access the kernel's syscalls directly and requires routing these calls through the platform's libc.

There is another case: using cgo which is a layer to interface Go code with foreign C code. Using cgo makes your Go program depend on the C runtime. Note that you might not use cgo directly but one or more of the third-party packages you might be using can use cgo, and—transitively—your program ends up depending on the C runtime library.