Does Go depend on C runtime?

Question

I can't find info does Go depend on C runtime? If it depends on it, is it statically compiled into the binary to make the application written in Go work everywhere without dependencies?

Here is the topic about what C runtime is

Answer 1

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.

Answer 2

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 3

If you mean LibC, Go does not depend on it. Go has its own standard library that includes implementations of commonly used functions such as file I/O, networking, and memory management, so it does not rely on libc or any other external library.