statically linked binary

[eternal-flame-AD]

Currently, the provided executable is dynamically linked and will refuse to start on machines with obsolete GLIBC versions. (prior to GLIBC 2.28, which is released on Aug 2018) Since we are not using sqlite3 extensions, it is still possible to produce a statically linked build with no dependency on GLIBC except for the plugin functionality.

I have tested the following command which successfully compiled a statically linked binary with GLIBC 2.28 which can be run on a machine with GLIBC 2.27.

$ CGO_ENABLED=1 CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ GOOS=linux GOARCH=arm64 go build -a -ldflags '-w -linkmode external -extldflags "-static"' -tags 'netgo osusergo sqlite_omit_load_extension'
# github.com/gotify/server
/usr/lib/go/src/plugin/plugin_dlopen.go:19: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

This would allow us to enjoy the priviledge of real portable binaries from go, which might be helpful for those running legacy systems such as referred in #131, but it would also render the plugin functionality not very useful:(

@jmattheis What do you think, should we document this as a last resort for compatibility problems, or include statically linked ones in releases?

[jmattheis]

Currently, the provided executable is dynamically linked and will refuse to start on machines with obsolete GLIBC versions. (prior to GLIBC 2.28, which is released on Aug 2018)

Are you sure? The docker image has GLIBC 2.24, or am I looking at the wrong place?

λ docker run --rm -v "$PWD/.:/proj" -w /proj gotify/build-test:1.12.0-linux-amd64 ldd --version 
ldd (Debian GLIBC 2.24-11+deb9u3) 2.24
Copyright (C) 2016 Free Software Foundation, Inc.
[...]

A real statically linked binary seems like a good idea, we could release both a dynamically linked binary with plugin support and a statically linked binary for compatibility and older systems.

[eternal-flame-AD]

Yes, all docker build environments have GLIBC 2.24. Previous releases built on travis environment has 2.28.

[ScrumpyJack]

Static build would be good. This is go after all, and it would work on non-glibc environments

[Tuxdude]

I know this discussion is more than four years old and given now we have gorm v2, as well as a pure go based sqlite driver (https://github.com/glebarez/sqlite).

This does however require migrating from gorm v1 (i.e. github.com/jinzhu/gorm) to v2 (i.e. gorm.io/gorm).

This would allow a CGO free statically linked binary for the gotify server.

[eternal-flame-AD]

@Tuxdude Thanks! I will look into it! I am mainly concerned with the reliability of the translated sqlite engine but it looks promising