Использование go с динамически связанными библиотеками C и несколькими проектами

Полезный шаблон, который мы приняли, использует Go для создания интерфейсов вокруг наших внутренних разделяемых библиотек C ++ 11 с использованием cgo.

Мы просто добавляем /gointerface dir к нашему проекту C ++, добавьте main.goскопировать в libfoo.so, бежать go build . тогда застегни это & отправим его.

К сожалению, когда мы хотим использовать другие зависимости Go, все становится сложнее, потому что у Go есть четкое мнение о том, где должен жить код и как он должен быть построен.

При создании нескольких пакетов из $GOPATH, go build . строит вне источника. Это делает недействительными пути к нашей динамической библиотеке — все флаги компоновщика относятся к исходному каталогу, а не к каталогу сборки.

В частности, -L путь, который ранее работал в плоском проекте, больше не ссылается на правильное место, поскольку он берется относительно каталога сборки.

// #cgo LDFLAGS: -Wl,-rpath -Wl,\$ORIGIN -L. -lfoo

Этот вопрос был поднят и сбит ранее, например,
https://go-review.googlesource.com/#/c/1756/

Но я еще не нашел хорошего решения для этого. В настоящее время путь наименьшего сопротивления состоит в том, чтобы просто свести все зависимости в один и тот же проект … что нежелательно.

Есть ли решение, которое не включает взлом абсолютных путей к переменным окружения или подрыв системы сборки Go?