5 ms·

I know, I said "Go" can't. Sorry if that isn't clear.

e12e 12y ago
I was recently surprised by this, when I tried to run a simple go web server in a chroot -- Apparently go defaults to dynamically linking to the host c libraries for domain lookups (partly this has to do with it being hard to do this with static code on OS X apparently). The upshot is that while "go build" might be expected to create a static binary (that should be easy to run in a chroot) -- in practice it won't unless you manually rebuild your go toolchain, passing in a parameter to avoid cgo/linking to c libraries for name lookup.
- f2f 12y ago
  if you build with CGO_ENABLED=0 then you'll have fully static go binaries on osx (but TLS won't work)
  - ominous_prime 12y ago
    TLS will work, you just can't pull the host CA bundle (osx keeps it in the keychain), so certificate verification won't work without proving your own.
  - e12e 12y ago
    It's my understanding that you have to do this on Linux as well, and it isn't enough to just build your project with CGO_ENABLED=0, you'll also have to rebuild the go-toolchain with CGO_ENABLED=0 for it to work. But perhaps this has changed in recent versions of go? Eg: cd /tmp git clone git@github.com:apg/wipes.git wipes.git cd wipes.git/ go get github.com/gorilla/websocket go get github.com/gorilla/websocket go build ldd wipes.git # > libc.so.6 among others export CGO_ENABLED=0 go build # makes no difference, produces identical binary Afaik, in this case it's 'net/http' that pulls in a dependency on cgo (again, unless we rebuild the whole go toolchain with cgo_enabled=0). Not that this is terrible as such, but it's a gotcha if you want to run the resulting binary in a chroot, or on a host with a different version of libc...
    - f2f 12y ago
      > But perhaps this has changed in recent versions of go? it hasn't. i meant 'if you build go with CGO_ENABLED=0' but was unclear.
    - stock_toaster 12y ago
      > Afaik, in this case it's 'net/http' that pulls in a > dependency on cgo (again, unless we rebuild the whole > go toolchain with cgo_enabled=0). You can also build with '-tags netgo'[1], and use go for name resolution, but still use cgo for when else you may need it. [1]: http://dominik.honnef.co/go-tip/2013-09-07/#netgo http://dominik.honnef.co/go-tip/2013-09-07/#netgo
      - e12e 12y ago
        Indeed: go install -a -tags netgo std go build -tags netgo ldd wipes.git not a dynamic executable Thanks for the tip :)
georgemcbay 12y ago
By that criteria Go doesn't have any support for DLLs either at the core language level, it just happens to export some Win32 API functions (LoadLibrary, GetProcAddress, etc) via goc (like cgo but specific to the Go bootstrapping build process) in the win32 version of the syscall package that allow you to do your own DLL late binding.
- 4ad 12y ago
  Goc is nothing like cgo. Goc is a simple preprocessor that allows writing C code with Go function declarations, and it will transform said code into C code compiled by 6c using some rules that are somewhat hard for people to do by hand and not screw up. For all practical purposes, goc is not required, people can write the C code by hand, it bears no effect on linking and on the ability to use code in external objects. Also, it's seldom used, most of the code is C code, not touched by goc. The Go linker does know how to link with external objects and use their symbols, and it does this without requiring the external object to be present at link time. It can do this, because the most basic relocations don't require any knowledge about the object. This was previously supported only on PE-COFF, as it was previously used by the Windows target, but now I have extended it to ELF too, and it's used on the Solaris target. In principle, it works on every other ELF platform too (Linux, *BSD). Note that in all of these cases ABI translation needs to be done, and the internal machinery in the runtime that does this is in motion, just like with cgo. There's no difference in the runtime performance envelope, the only difference is that it doesn't require a target toolchain, like cgo does.

e12e 12y ago

I was recently surprised by this, when I tried to run a simple go web server in a chroot -- Apparently go defaults to dynamically linking to the host c libraries for domain lookups (partly this has to do with it being hard to do this with static code on OS X apparently). The upshot is that while "go build" might be expected to create a static binary (that should be easy to run in a chroot) -- in practice it won't unless you manually rebuild your go toolchain, passing in a parameter to avoid cgo/linking to c libraries for name lookup.

f2f 12y ago
if you build with CGO_ENABLED=0 then you'll have fully static go binaries on osx (but TLS won't work)
- ominous_prime 12y ago
  TLS will work, you just can't pull the host CA bundle (osx keeps it in the keychain), so certificate verification won't work without proving your own.
- e12e 12y ago
  It's my understanding that you have to do this on Linux as well, and it isn't enough to just build your project with CGO_ENABLED=0, you'll also have to rebuild the go-toolchain with CGO_ENABLED=0 for it to work. But perhaps this has changed in recent versions of go? Eg: cd /tmp git clone git@github.com:apg/wipes.git wipes.git cd wipes.git/ go get github.com/gorilla/websocket go get github.com/gorilla/websocket go build ldd wipes.git # > libc.so.6 among others export CGO_ENABLED=0 go build # makes no difference, produces identical binary Afaik, in this case it's 'net/http' that pulls in a dependency on cgo (again, unless we rebuild the whole go toolchain with cgo_enabled=0). Not that this is terrible as such, but it's a gotcha if you want to run the resulting binary in a chroot, or on a host with a different version of libc...
  - f2f 12y ago
    > But perhaps this has changed in recent versions of go? it hasn't. i meant 'if you build go with CGO_ENABLED=0' but was unclear.
  - stock_toaster 12y ago
    > Afaik, in this case it's 'net/http' that pulls in a > dependency on cgo (again, unless we rebuild the whole > go toolchain with cgo_enabled=0). You can also build with '-tags netgo'[1], and use go for name resolution, but still use cgo for when else you may need it. [1]: http://dominik.honnef.co/go-tip/2013-09-07/#netgo http://dominik.honnef.co/go-tip/2013-09-07/#netgo
    - e12e 12y ago
      Indeed: go install -a -tags netgo std go build -tags netgo ldd wipes.git not a dynamic executable Thanks for the tip :)

georgemcbay 12y ago

By that criteria Go doesn't have any support for DLLs either at the core language level, it just happens to export some Win32 API functions (LoadLibrary, GetProcAddress, etc) via goc (like cgo but specific to the Go bootstrapping build process) in the win32 version of the syscall package that allow you to do your own DLL late binding.

4ad 12y ago
Goc is nothing like cgo. Goc is a simple preprocessor that allows writing C code with Go function declarations, and it will transform said code into C code compiled by 6c using some rules that are somewhat hard for people to do by hand and not screw up. For all practical purposes, goc is not required, people can write the C code by hand, it bears no effect on linking and on the ability to use code in external objects. Also, it's seldom used, most of the code is C code, not touched by goc. The Go linker does know how to link with external objects and use their symbols, and it does this without requiring the external object to be present at link time. It can do this, because the most basic relocations don't require any knowledge about the object. This was previously supported only on PE-COFF, as it was previously used by the Windows target, but now I have extended it to ELF too, and it's used on the Solaris target. In principle, it works on every other ELF platform too (Linux, *BSD). Note that in all of these cases ABI translation needs to be done, and the internal machinery in the runtime that does this is in motion, just like with cgo. There's no difference in the runtime performance envelope, the only difference is that it doesn't require a target toolchain, like cgo does.