statically linked binary
- 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
Assessment
This issue has not been assessed yet.