dynamically linked go binaries???

[brunetto]

Hi!!

I'm a bit confused.

I knew (https://golang.org/doc/faq) that go produces statically linked binaries.

It still does, for example, if I compile

$ cat test.go

package main

import (

       "fmt"

       "time"

       "github.com/brunetto/goutils/debug"

)

func main() {

     defer debug.TimeMe(time.Now())

     fmt.Println("hello, world!")

$ file test

test: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), statically linked, not stripped

$ ldd test

        not a dynamic executable

BUT, in other cases, and I can't figure where is the difference, I get (for example):

$ file $GOPATH/src/github.com/brunetto/sltools/cmd/sltools/sltools

sltools: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

$ ldd $GOPATH/src/github.com/brunetto/sltools/cmd/sltools/sltools

        linux-vdso.so.1 =>  (0x00007fff2fffe000)

        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0945d78000)

        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f09459b2000)

        /lib64/ld-linux-x86-64.so.2 (0x00007f0945fcb000)

Why is (for example) sltools dynamically linked? 

I'm not using cgo etc...

I search on internet but I can't find anything..

thanks

brunetto

[Konstantin Khomoutov]

On Thu, 18 Dec 2014 05:30:07 -0800 (PST)
brunetto <brunett...@gmail.com> wrote:

> I'm a bit confused.
> I knew (https://golang.org/doc/faq) that go produces statically
> linked binaries.

[...]

> BUT, in other cases, and I can't figure where is the difference, I
> get (for example):

[...]

Please read the intro in
https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/

[Harald Weidner]

Hello,

> I knew (https://golang.org/doc/faq) that go produces statically linked
> binaries.

> BUT, in other cases, and I can't figure where is the difference, I get (for
> example):

> sltools: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked (uses shared libs), not stripped

See https://groups.google.com/forum/#!topic/golang-nuts/Rw89bnhPBUI for a
discussion on this topic.

However, even if the binaries are "dynamically linked", they link only
against some basic Linux libraries, which are present on any recent Linux
system.

> $ ldd $GOPATH/src/github.com/brunetto/sltools/cmd/sltools/sltools
> linux-vdso.so.1 => (0x00007fff2fffe000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0945d78000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f09459b2000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f0945fcb000)

The Go runtime and libraries are included statically in the binary. There is
no need to install some "runtime environment" on the target host, as with
other programming languages.

Harald

[brunetto]

Please read the intro in
https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/

Thanks 

brunetto 

[brunetto]

See https://groups.google.com/forum/#!topic/golang-nuts/Rw89bnhPBUI for a
discussion on this topic.

Thanks, I tried

 go build -tags netgo -a 

 go build -tags netgo -a std

but it doesn't change anything

 

brunetto

[Konstantin Khomoutov]

On Thu, 18 Dec 2014 05:30:07 -0800 (PST)
brunetto <brunett...@gmail.com> wrote:

[...]

> sltools: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), not stripped

[...]

To be more specific, on Linux, networking code in the Go standard
library (the "net" package) by default links against libc to be able to
use its getaddrinfo(). The "os" package also links against libc to be
able to use its means for its "name service switch" interface to look
up users by their IDs and vice versa.

AFAIK, the Go's stdlib contains some code to work around absence of libc
on this platform which might be enabled by specially instrumenting
building of the Go suite but you should think thrice before considering
doing this if your program is of general purpose and not a part of some
embedded thing (like the busybox shell).

[Konstantin Khomoutov]

https://github.com/golang/go/issues/9344 ?

[brunetto]

Thanks

brunetto