`musl` systems not supported about zk

[tjex]

We cross compile with Docker images. If you change your mind about wanting to contribute, we'd welcome a PR to zk-xcompile (from those current images, you can easily infer what would need to be in an Alpine based image, also better than me personally as I have no experience with musl) with a golang 1.21 image based from Golang's Alpine images.

For the next release of zk we could well have migrated away from needing Docker images for cross compilation, and will be able to do it natively. As the next release is potentially a few hours away 0.14.1, I'm resistant to setting up an Alpine Docker image for this (potentially) singular minor release.

Alternatively, building zk from source is very user friendly (thanks to Go). So you can always go via that route.

Clone zk, cd zk and make install.

[tjex]

Was curious, and had a bit of a go: https://github.com/tjex/zk-xcompile/tree/alpine

But attempting to compile results in many complaints about sqlite bindings (which is the dep that requires CGO).
Happy to work with you or someone else on this or receive a direct PR, but I don't want to commit solo time to this currently.

[notramo]

Upgrading go-sqlite3 to 1.14.19 should fix the issue:
https://github.com/mattn/go-sqlite3/releases/tag/v1.14.19
(related issue and PR)

As suggested here, adding CGO_CFLAGS="-D_LARGEFILE64_SOURCE" to the environment serves as a temporary workaround, however this might break some other platforms. But I managed to build zk with the current go-sqlite3 version and this variable.

Some comments suggests that despite the fix in 1.14.19, it still fails on Alpine 3.19, but using Alpine 3.18 works. However, this might be fixed since, so I would suggest trying with latest first.

[tjex]

Ah great, thanks for working with me to get the necessary info.

Bumping sqlite version built successfully with golang 1.21 and latest alpine build.

file returns this info:

zk: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, BuildID[sha1]=e2ac8e6f536b3ae1e4c740e12ec82a601fad41bd, with debug_info, not stripped

I'm not so learned with compilation, and you did mention to statically link, but here it's stated linking was dynamic. In any case, could you download the binary and report back if it runs, @notramo ?

zk-v0.14.1-alpine-amd64.tar.gz

[notramo]

It will crash on glibc systems since it dynamically links musl. It's still dynamically linked, but with a different libc.
However, the compilation succeeded with the updated lib version, so we're getting closer.
According to this article, adding -extldflags=-static to the -ldflags value will switch to static compilation. Makefile snippet for this project after it's added:

# Wrapper around the go binary, to set all the default parameters.
define go
	$(ENV_PREFIX) go $(1) -tags "fts5" -ldflags "-extldflags=-static -X=main.Version=$(VERSION) -X=main.Build=$(BUILD)" $(2)
endef

I tried compiling with this modification and it resulted in a static binary (file output says statically linked, and no interpreter= is specified).

[tjex]

awesome, thanks again.

Here are two new binaries. Could you test the one for your arch? And ideally if you know someone who can run the other as a sanity check, it would be ace.

The following test should be adaquate:

cd ~
mkdir zk-test && cd zk-test
zk init

setup as desired

zk new --title "test note"

close

zk index

zk-v0.14.1-musl-amd64.tar.gz
zk-v0.14.1-musl-i386.tar.gz

[notramo]

I only have amd64 arch with musl. Tested both binaries, they work out of the box. I couldn't test the i386 on a 32 bit machine, however it works on my amd64 system.

Also tested it in a Docker container running Debian, to see if it works on a glibc system too. Works out of the box.

I think it can be considered solved.

@tjex thanks for adding this feature.

[tjex]

Fantastic. Thanks for the extra testing and information. Really appreciated 🙌
You're welcome, thanks for requesting and helping along the way. Glad that the musl peeps can get Zetteling 😁