Compile statically linked with musl as an alternative to the non cgo version

[gmbuell]

I would love to use this under alpine linux which does not have glibc. Unfortunately, the resolver mode does not work in the non-cgo version. Linking with musl libc should provide the needed functionality but currently a musl built version will segfault.

[hlandau]

"Currently a musl built version will segfault".

I've tried this myself and it works if built on Alpine Linux (see APKBUILD linked in README), so I assume you're talking about building using musl from another distro. Which does indeed appear to crash. But you can work around this by passing -fno-PIC or -static to the linker. Indeed Alpine's Go packaging patches Go to always pass -fno-PIC.

Currently I have this for dynamically linked builds:

CC=/usr/bin/musl-gcc go build --ldflags \
  '-linkmode external -extldflags "-fno-PIC -L /path/to/directory/containing/libcap.a/taken/from/alpine"' \
  github.com/hlandau/acme/cmd/acmetool

Replace -fno-PIC with -static for static builds. Confusingly Alpine's ldd says that the dynamically linked version is not a dynamically linked executable even though it definitely is.

Might be able to provide these binaries in the future.

[hlandau]

I figure things should be rearranged to provide the following possibilities:

linux_amd64.tar.gz -- musl static
linux_amd64_musl.tar.gz -- musl dynamic
linux_amd64_glibc.tar.gz -- glibc dynamic
linux_amd64_nocgo.tar.gz -- nocgo
openbsd_amd64_nocgo.tar.gz -- nocgo

Probably don't want to provide all of these, that would be excessive.

[gmbuell]

I don't think there's much use in a dynamic musl build but I would certainly love a provided musl static build.

[kkofler]

You also need to link libcap statically if you want to do a true static build.