Container image - another flavor besides alpine (libc.musl)

[MichaelGissingNC]

Hi,

TL;DR: I build a release inside goreleaser/goreleaser image on GitLab CI and want to use the binaries on Debian/Ubuntu systems.

we use GitLab so I followed https://goreleaser.com/ci/gitlab/
Basically it works fine, my release gets created. However, after downloading the released binary, it just didn't run on my machine.
After looking around, I understood that goreleaser/goreleaser is based on alpine and thus the binary is dynamically linked against libc.musl-x86_64.so.1 - which I don't have on my Ubuntu based installation.

I'll try to create a static binary to work around this for my current situation.
However, I was a bit surprised by this whole situation and it was quite time consuming. But I also learned quite a bit about go and the eco system - so for me it was OK. I just want to help others as well.

I also found this issue #2142 - I suspect that there was the same confusion. Not the usage of docker was the issue but that it was linked against musl. (My guess)

It's even more confusing as the official golang image is based on Debian (tag 1.18 will give you a bullseye based image), so it produces binaries that are executable on my Linux when I build it in a container.

So my idea to solve this would be to:

• Create an additional goreleaser/goreleaser image based on Debian/libc. My usecase for creating releases in GitLab is to provide users in the organization a CLI tool. So the binary they download from the release page should be executable by them. I would then use the new image in my .gitlab-ci.yml and I would automatically get a binary that would work for (most) my Linux users. (I still have to test the other way round - I guess a libc binary will fail when used in alpine.)

• Also adapt the GitLab CI documentation that it's based on alpine to hint that it will not produce truly portable binaries if they are dynamically linked. (This might be obvious to experienced go users but was surprising to me)

As stated above I will try to create static binaries to prevent this from happening at all and solve it for me.

[caarlos0]

the problem seems to be you're using cgo, in that case just changing it libc would probably just change the errors you'd have.

take a look at https://github.com/goreleaser/goreleaser-cross

and, if you don't really need cgo, the easiest way is to disable CGO in your builds.