gotify / gotify/server

statically linked binary

Open
#133 5 comments 0 reactions 0 assignees View on GitHub
a:feature in:server
Dominant language
Go
Stars
15.9k
Forks
873
Avg merge
2d 22h
Merged PRs (30d)
6

Description

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.
```bash
$ 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?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.