A useful pattern we have adopted is using Go to build interfaces around our internal C++11 shared libraries using cgo.
We simply add a /gointerface dir to our C++ project, add a main.go, copy in libfoo.so, run go build . then zip it & ship it.
Unfortunately, when we want to use other Go dependencies, things start getting complicated because Go has strong opinions about where code should live and how it should be built.
When building multiple packages from a $GOPATH, go build . builds out-of-source. This invalidates the paths to our dynamic library - the linker flags are all relative to the source dir, not the build dir.
In particular, the -L path that previously worked in the flat project no longer refers to the correct place, since it is taken relative to the build directory.
// #cgo LDFLAGS: -Wl,-rpath -Wl,\$ORIGIN -L. -lfoo
This issue has been raised and shot down before, e.g. https://go-review.googlesource.com/#/c/1756/
But I've yet to find any good solution to it. Currently the path of least resistance is to just flatten all dependencies into the same project... which is undesirable.
Is there a solution that doesn't involve hacking absolute paths into environment variables or subverting the Go build system?