我们采用的一种有用的模式是使用Go来使用cgo围绕我们的内部C ++ 11共享库构建接口。
我们只需在我们的C ++项目中添加/gointerface目录，添加main.go，复制到libfoo.so，然后运行go build .，然后将其压缩为＆amp;发货。
不幸的是，当我们想要使用其他Go依赖项时，事情开始变得复杂，因为Go对代码应该存在的位置及其构建方式有很强的意见。
从$GOPATH构建多个软件包时，go build .构建非源代码。这使我们的动态库的路径无效 - 链接器标志都是相对于源目录的，而不是构建目录。
特别是，之前在平面项目中工作的-L路径不再引用正确的位置，因为它是相对于构建目录的。
// #cgo LDFLAGS: -Wl,-rpath -Wl,\$ORIGIN -L. -lfoo
这个问题在之前被提出并被击落，例如 https://go-review.googlesource.com/#/c/1756/
但我还没有找到任何好的解决方案。目前，阻力最小的路径是将所有依赖关系扁平化为同一个项目......这是不可取的。
是否有解决方案不会将绝对路径入侵环境变量或破坏Go构建系统？