On Mon, Nov 17, 2014 at 1:12 PM, Marvin Humphrey <[email protected]> wrote:
> * Clownfish-powered code ends up linked statically into Go binaries --
> avoiding all the permissions, versioning and deployment complications of
> dynamic linking to shared libraries outside of $GOPATH.
> * Clownfish headers get installed into a dedicated subdir of $GOPATH/pkg.
One distinctive aspect of Go is that binaries are statically linked. It's
typical for CGO projects to link to a shared library nevertheless (this is how
golucy works), but that approach has a number of drawbacks.
1. You have to perform separate actions to install the shared library,
usually to a global location where permissions have to be dealt with.
2. The shared library may not be present on machines you want to deploy to.
3. The shared library and the Go binary not updated by the same regime and
may get out of sync.
So, instead of creating a shared library, we create a static library for each
Clownfish-powered project, installing it into a special location under `pkg`.
Go packages are also compiled to a static archive by `go build`/`go install`.
Ideally, we would simply embed the content of our own static archive
into theirs.
However, C symbols in those Go static archives are not visible, which is a
showstopper -- it would make it impossible to "see" the Clownfish C ABI when
linking Lucy, for example. Thus the need for two separate static archives.
github.com/example/foo.a
github.com/example/foo/_lib/libfoo.a
We also install Clownfish headers under `pkg`, into a dedicated directory.
pkg/GOOS_GOARCH/git-wip-us.apache.org/repos/asf/lucy-clownfish.git/_include
Marvin Humphrey
