build: Statically link the toolbox binary #531
Conversation
The Go implementation of Toolbox uses in few places code written in C (not directly in the Toolbox code but in some library). This causes Toolbox to be dynamically linked to the systems C library (libc). Under other circumstances this would not be a problem but Toolbox itself is being used as the entry-point of toolbox containers. The most widely used implementation of libc is glibc. Its versions seem to be backwards-compatible but not forward-compatible, making Toolbox unusable in older distros that ship a previous version of glibc. One of the solutions is to statically link libc (resp. glibc) which is what this commit does. The size of the final binary seems to not be affected. CGO_ENABLED=0 forces the build not to use cgo making it effectively statically linked and '-tags osusergo' forces the use of purely Go implementation of os/user. https://golang.org/pkg/os/user/ https://golang.org/cmd/cgo/ containers#531
HarryMichal
force-pushed
the
statically-link-toolbox
branch
from
e4755b3 to
b09fa3a
Compare
|
Build failed.
|
The Go implementation of Toolbox uses in few places code written in C (not directly in the Toolbox code but in some library). This causes Toolbox to be dynamically linked to the systems C library (libc). Under other circumstances this would not be a problem but Toolbox itself is being used as the entry-point of toolbox containers. The most widely used implementation of libc is glibc. Its versions seem to be backwards-compatible but not forward-compatible, making Toolbox unusable in older distros that ship a previous version of glibc. One of the solutions is to statically link libc (resp. glibc) which is what this commit does. The size of the final binary seems to not be affected. CGO_ENABLED=0 forces the build not to use cgo making it effectively statically linked. https://golang.org/pkg/os/user/ https://golang.org/cmd/cgo/ containers#531
HarryMichal
force-pushed
the
statically-link-toolbox
branch
from
b09fa3a to
6da30b6
Compare
|
Build failed.
|
There was a problem hiding this comment.
Thanks for coming up with a solution so fast, @HarryMichal !
What worries me is that the pure Go alternative in the os/user package doesn't have all the bells and whistles as the one using the standard C library. I am thinking of enterprise set-ups where the user and group information might not be coming from /etc/passwd and /etc/group but from some directory service.
The net package also uses the standard C library for name resolution. Disabling the C code with CGO_ENABLED=0 means that we will end up with the more limited pure Go resolver that directly uses /etc/resolv.conf instead of going through the C APIs. This won't be very future-proof because upstream systemd-resolved suggests deprecating /etc/resolv.conf as seen in the switch in Fedora.
As far as I can make out, we don't actually use the net package right now. However, since Toolbox is in the business of fetching images, it's possible that it might end up picking up a dependency further down the road.
Therefore, I am slightly leaning towards #534 at the moment, if it holds up in testing.
|
Let's close this for the time being. However we can revisit if the approach in #534 doesn't pan out. |
|
#832 contains the discussion around static builds and disabling CGO. |
The Go implementation of Toolbox uses in few places code written in C
(not directly in the Toolbox code but in some library). This causes
Toolbox to be dynamically linked to the systems C library (libc). Under
other circumstances this would not be a problem but Toolbox itself is
being used as the entry-point of toolbox containers. The most widely
used implementation of libc is glibc. Its versions seem to be
backwards-compatible but not forward-compatible, making Toolbox unusable
in older distros that ship a previous version of glibc.
One of the solutions is to statically link libc (resp. glibc) which is
what this commit does. The size of the final binary seems to not be
affected.
https://golang.org/pkg/os/user/
https://golang.org/cmd/cgo/