Using binary packages directly

Question

I'm writing a library in Go. I'm planning to distribute it, and with a main requirement of 'without source codes'.

For testing, I have created two workspaces like following,

WS1

• bin/
• pkg/linux_amd64/lib.a
• src/lib/src.go

WS2

• bin/
• pkg/
• src/main/main.go

My first workspace (WS1) is the actual dummy library, which has some utility functions. Second workspace (WS2) has main function which uses the package (lib.a) from WS1.

Everything was working good until I remove the sources from WS1. If I remove the directory /lib/src.go in WS1, I'm getting the following error during go build,

main.go:5:2: cannot find package "lib" in any of: /usr/local/go/src/pkg/lib (from $GOROOT) ../Testing/ws1/src/lib (from $GOPATH)

The above message indicates us that we should keep the source files as well. Precompiled binary packages alone cannot be used directly.

Based on few suggestions online, we may keep some dummy sources with timestamp value lesser than binary packages' timestamp. But, this doesn't seems to be a feasible solution for us. What happens if timestamp of the dummy sources got updated unfortunately?

I have seen similar issue discussed here, https://github.com/golang/go/issues/2775

My Questions:

1. Distributing the sources is the only possibility in Golang?

2. Why Go is not providing a provision for using '.a' files directly?

3. If keeping the source is mandatory for Go, why this small thing is not mentioned anywhere in Go? (or) Am I missing something here?

Thanks in advance for your help guys!

Answer 1

The Go compiler just needs the .a files. If you ship them anybody will be able to use your package without the source code.

BUT your users will have to invoke the compiler (e.g. 6g, not the go tool) manually. If you ship a myfoo.a file and a dummy source myfoo.go containing just package myfoo and the timestamp of myfoo.a is newer than that of myfoo.go (and you put everything in place) you may use the go tool.

Update: Newer version of the go tool detect deleted files and require all files (possibly empty) with the proper filenames and older timestamps in the src folder. Managing a timestamp should not be a dealbreaker.

Don't get fooled that the go tool is Go: It is a dead convenient tool to build, test, get, whatever your Go code, but it is neither the language nor the compiler nor the linker.

BTW: There is really no point in not distributing the sources.

Answer 2

The binary-only packages will be available in go1.7 (August 2016) - https://tip.golang.org/doc/go1.7

This release adds experimental, minimal support for building programs using binary-only packages, packages distributed in binary form without the corresponding source code. This feature is needed in some commercial settings but is not intended to be fully integrated into the rest of the toolchain. For example, tools that assume access to complete source code will not work with such packages, and there are no plans to support such packages in the “go get” command.

The proposal is at https://github.com/golang/proposal/blob/master/design/2775-binary-only-packages.md , https://tip.golang.org/pkg/go/build/#hdr-Binary_Only_Packages has more information about the new feature.