search

awslabs / soci-snapshotter

A containerd snapshotter plugin which enables standard OCI images to be lazily loaded without requiring a build-time conversion step.
Apache License 2.0
534 stars 55 forks source link

[FEATURE] Statically link binaries #475

Closed Kern-- closed 1 year ago

Kern-- commented 1 year ago

Description

Currently, soci and soci-snapshotter-grpc are dynamically linked against zlib and glibc. This requires consumers of SOCI to have a compatible version of libc and libz in order to use either program and means that there is no guarantee that our released binaries will work for a particular user.

Describe the solution you'd like

We should offer a mechanism to build static binaries and include those static binaries in our releases. This will remove the need for most runtime dependencies and allow our release binaries to run on any linux system.

Describe any alternative solutions/features you've considered

We can alternatively be careful to build releases against older versions of glibc and keep our zlib api surface small to avoid ABI changes and unknown symbols.

Any additional context or information about the feature request

No response

Kern-- commented 1 year ago

This should also include an analysis on whether statically linking is the right thing to do.

For example, go and nerdctl build static binaries by default, but containerd discourages it

Kern-- commented 1 year ago

Using a combination of #476 and adding -linkmode "external" -extldflags "-static" to ldflags (as noted by https://mt165.co.uk/blog/static-link-go/) looks pretty good.

dyanmically linked:

$ ls -lh out
total 66M
-rwxr-xr-x 1 admin admin 26M Mar  8 23:01 soci
-rwxr-xr-x 1 admin admin 41M Mar  8 23:01 soci-snapshotter-grpc

statically linked:

$ ls -hl out
total 64M
-rwxr-xr-x 1 admin admin 22M Mar  8 23:51 soci
-rwxr-xr-x 1 admin admin 42M Mar  8 23:51 soci-snapshotter-grpc

# just to convince myself
$ ldd ./out/soci
    not a dynamic executable
$ ldd ./out/soci-snapshotter-grpc 
    not a dynamic executable
Kern-- commented 1 year ago

I do see a bunch of warnings, though. I'm not sure if these are things that we don't call or if we still implicitly depend on glibc.

/usr/bin/ld: /tmp/go-link-3718045094/000024.o: in function `mygetgrouplist':
/_/os/user/getgrouplist_unix.go:15: warning: Using 'getgrouplist' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-3718045094/000023.o: in function `mygetgrgid_r':
/_/os/user/cgo_lookup_unix.go:37: warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-3718045094/000023.o: in function `mygetgrnam_r':
/_/os/user/cgo_lookup_unix.go:42: warning: Using 'getgrnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-3718045094/000023.o: in function `mygetpwnam_r':
/_/os/user/cgo_lookup_unix.go:32: warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-3718045094/000023.o: in function `mygetpwuid_r':
/_/os/user/cgo_lookup_unix.go:27: warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/go-link-3718045094/000004.o: in function `_cgo_2ac87069779a_C2func_getaddrinfo':
/tmp/go-build/cgo-gcc-prolog:58: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking