The go command supports "binary-only packages", in which the compiled .a file is installed in GOROOT/pkg or GOPATH/pkg but the corresponding source code is only a stub with relevant imports (for linking), a special comment marking it as a binary-only package, and perhaps documentation for exported API.
While the go command will use these packages if they exist in GOROOT or GOPATH, 'go get' will not download them: 'go get' is intentionally only about source code distribution. Furthermore, binary-only packages only work when the build is using the exact versions of whatever imported packages are needed by the binary-only package. If there were any important differences in a dependency between compilation and linking, the binary-only portion might have stale information about details of the imported package, such as type sizes, struct field offsets, inlined function bodies, escape analysis decisions, and so on, leading to silent memory corruption at runtime. Binary-only packages also only work when the build is using the exact version of the Go toolchain that was used for compilation. This is at least enforced at link time, with the effect that if your binary-only package only imports the standard library and you don't use any special compilation flags, then the toolchain version check suffices to avoid the silent memory corruption problem described in the previous package. But if your package imports any non-standard package for which that the eventual user might try to combine with a different version, you're in trouble again. Compiled Go programs also contain much richer amounts of runtime information than compiled C programs, so that for example all the details of type declarations, including struct definitions, are in the compiled code, along with file names and line numbers for the compiled code, and increasingly good debug information that was impossible to turn off until very recently. Overall, a binary-only package obscures very little. In short, binary-only packages: - have never been supported by 'go get', so you've had to go out of your way to use them, - aren't even guaranteed to work when you do use them, possibly leading to silent memory corruption, and - still expose quite a lot more than most people would expect about the original source code. For these reasons, we're looking at removing binary-only package support entirely. If you use binary-only packages and think it's important to keep that support around, please let us know either on this thread or at golang.org/issue/28152. Thanks. Russ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
