Static binary artifacts for CI releases

Building/Development
1

Hello!

Has adding statically linked binary artifacts in the CI release builds been considered?

As a NixOS user, the available OpenZiti binary release builds don’t work out of the box because nix uses a filename hashed store for OS binaries and other artifacts to achieve various operational benefits.

To get the OpenZiti tunneler to work, for example, I need to manually patch the release binary from FHS paths to nix hashed store paths, example:

# Example patch required for release binary:
# https://github.com/openziti/ziti-tunnel-sdk-c/releases/download/v0.19.11/ziti-edge-tunnel-Linux_x86_64.zip

# Due to not found .so in ldd output
patchelf --set-interpreter $(nix-build "<nixpkgs>" -A glibc --add-root ~/.cache/gcroots/glibc --indirect --no-out-link)/lib/ld-linux-x86-64.so.2 ./ziti-edge-tunnel

# Due to errors in the client tunnel log about not being able to find a dynamically loaded systemd library:
patchelf --add-needed $(nix-build "<nixpkgs>" -A systemd --add-root ~/.cache/gcroots/systemd --indirect --no-out-link)/lib/libsystemd.so.0 ./ziti-edge-tunnel

A static build, maybe with musl, and including all libs needed should be more portable and work directly on NixOS also.

As an alternative, we’re looking at doing some NixOS packaging for OpenZiti, but this probably won’t happen for a little while. So I’ll be using patched release builds for now, or running within docker on other OSs as a last option.

2

Hi!

This is a great question, thanks!

Doing this certainly isn’t out of the question but we haven’t had much demand for it at this point (afaik).

We haven’t given much thought to static builds for our pre-built binaries yet, since the binaries are sufficient for the primary distros, and users who aren’t on the big distros are usually ok with (and sometimes need to - e.g. openwrt) building their own binary from source.

Our CI builds currently are linked against glibc, which as you may know can lead to some surprises when linked statically. So (as you allude to) if we were to provide statically linked builds we would want to musl or another library that behaves correctly when linked statically.

1 Like
3

Hi @scareything, thanks for explaining. Sure, I do understand there may not have been much demand for static builds so far. I’ll keep pushing forward on a Nix build for our use case as we can find the time.

Thanks,
John