Open bschofield opened 4 years ago
What changes would be required to avoid having to distribute a binary library?
In this case you should run make libzstd.a
after go get github.com/valyala/gozstd
. Unfortunately Go cannot build libzstd.a
during go get
from the unmodified upstream code inside zstd directory. Go can automatically build only *.c
and *.h
files inside the same directory as *.go
files. It doesn't know how to build *.c
files inside other directories such as zstd
directory :(
OK, thanks!
For anyone else having this issue, here is an updated one-liner which can be placed in your .gitlab-ci.yaml
to automatically pull the version of this library specified in go.mod
before cleaning and rebuilding the .a
files:
- BUILD_DIR=$(pwd); GOZSTD_VER=$(cat go.mod | fgrep github.com/valyala/gozstd | awk '{print $NF}'); go get -d github.com/valyala/gozstd@${GOZSTD_VER}; cd ${GOPATH}/pkg/mod/github.com/valyala/gozstd@${GOZSTD_VER}; if [[ ! -f _rebuilt ]]; then chmod -R +w .; make -j8 clean; make -j8 libzstd.a; touch _rebuilt; fi; cd ${BUILD_DIR}
The one-liner makes a marker file _rebuilt
inside the module directory, so if you are caching build dependencies then the rebuild only has to happen once. The chmod is required because of https://github.com/valyala/gozstd/issues/6.
FYI, bundle for alpine linux with musl is supported now, you have to provide build tag for it. It can be done with command:
go build -tag 'musl'
https://github.com/valyala/gozstd/blob/master/libzstd_linux_musl_amd64.go
Should be
go build -tags 'musl'
Firstly, thanks a lot for making this. I was experiencing https://github.com/DataDog/zstd/issues/22 and switching over to this library seems to have solved that problem, with a minimum of code changes.
My issue is that I deploy my golang application in docker containers. I use Alpine Linux as my deployment base in order to reduce the container sizes. Because Alpine uses musl instead of glibc, the pre-compiled binaries you distribute cannot work with Alpine. Instead, at build time errors like this are generated:
I can work around this by putting in special case code into my build process just for this module, something like
...but it feels quite unusual to have to do that.
What changes would be required to avoid having to distribute a binary library?