Fixing static binary build using container#670
Fixing static binary build using container#670vijaySamanuri wants to merge 2 commits intocontainers:masterfrom
Conversation
vijaySamanuri
commented
Jun 11, 2019
vijaySamanuri
commented
- LookupId panics on Linux+glibc static build (os/user: LookupId panics on Linux+glibc static build golang/go#24787)
- Updated go version to 1.11.0 in Dockerfile.build
- added go build tags netgo osusergo in static binary
|
LGTM |
|
@vijaySamanuri You need to sign your commit. git commit -a -s --amend |
|
|
||
| ifeq ($(DISABLE_CGO), 1) | ||
| override BUILDTAGS = containers_image_ostree_stub exclude_graphdriver_devicemapper exclude_graphdriver_btrfs containers_image_openpgp | ||
| override BUILDTAGS = netgo osusergo containers_image_ostree_stub exclude_graphdriver_devicemapper exclude_graphdriver_btrfs containers_image_openpgp |
There was a problem hiding this comment.
Thanks for the PR.
netgobypasses NSS, including the glibc resolver (per https://golang.org/pkg/net/ , e.g. breaking.localnames.osusergobypasses NSS as well, breaking e.g. LDAP uses.
Yes, I realize that these downsides are fundamentally necessary to make static builds work at all, but they are significant downsides.
I’m sorely tempted to just remove any mention of statically-linked or non-CGo builds from the repository (@rhatdan WDYT?).
If not that, at the very least README should document these downsides of a static build as well.
There was a problem hiding this comment.
I would hate to remove them, since it seems many in the GO world seem to want/require them. I guess Documenting the shortcomings is the best solution.
The NSS stuff is only important for rootless container/storage I believe?
1. LookupId panics on Linux+glibc static build (golang/go#24787) 2. Updated go version to 1.11.0 in Dockerfile.build 3. added go build tags netgo osusergo in static binary Signed-off-by: vijaysamanuri <vijay.samanuri@wavemaker.com>
|
@vijaySamanuri Are you still interested in completing this? |
|
I think we should move forward with this and just document the shortcomings of a static built version of skopeo. |
|
@vrothberg Worth taking this over, or should we just close it? |
I have a tendency to close. I'm skeptical toward static when it's not fully supported - shall we drop the make target? |
|
Ideally, I’d prefer dropping both statically-linked builds for Linux (which are unreliable and functionally restricted) and in-container builds (which are a good idea in theory, but keep breaking because we don’t use them, and don’t work with dynamically-linked builds). Dropping the statically-linked targets would be a good first step — though this PR suggests that the in-container builds might also be broken, independently. |
|
+1, I'll create an issue for it. |
5 participants
