Reduces the binary size (39810466 - 39289106 => 521360 (521 kb)
We only import google.golang.org/grpc as an indirect dependency, and
do not make gRPC connections.
grpcnotrace avoids importing golang.org/x/net/trace, which in turn enables
dead code elimination, which can yield 10-15% improvements in binary size
when tracing is not needed.
see https://github.com/grpc/grpc-go/blob/v1.81.1/trace_notrace.go#L23-L25
Before:
ls -l ./build/docker-darwin-arm64
-rwxr-xr-x 1 thajeztah staff 39810466 May 22 11:44 ./build/docker-darwin-arm64*
ls -lh ./build/docker-darwin-arm64
-rwxr-xr-x 1 thajeztah staff 38M May 22 11:44 ./build/docker-darwin-arm64*
After:
ls -l ./build/docker-darwin-arm64
-rwxr-xr-x 1 thajeztah staff 39289106 May 22 11:45 ./build/docker-darwin-arm64*
ls -lh ./build/docker-darwin-arm64
-rwxr-xr-x 1 thajeztah staff 37M May 22 11:45 ./build/docker-darwin-arm64*
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 880ef756b7 fixed static builds with
CGO, which included setting the `netgo` build-tag for static builds.
Starting with go1.19, the Go runtime on Windows now supports the `netgo` build-
flag to use a native Go DNS resolver. Prior to that version, the build-flag
only had an effect on non-Windows platforms. From the go1.19 release notes:
https://go.dev/doc/go1.19#net
> Resolver.PreferGo is now implemented on Windows and Plan 9. It previously
> only worked on Unix platforms. Combined with Dialer.Resolver and Resolver.Dial,
> it's now possible to write portable programs and be in control of all DNS name
> lookups when dialing.
>
> The net package now has initial support for the netgo build tag on Windows.
> When used, the package uses the Go DNS client (as used by Resolver.PreferGo)
> instead of asking Windows for DNS results. The upstream DNS server it discovers
> from Windows may not yet be correct with complex system network configurations,
> however.
This originally caused issues in the daemon, because the pure-go implementation
did not respect file-based resolution (`C:\Windows\System32\Drivers\etc\hosts`),
resulting in `localhost` not being resolvable, and custom entries in `.etc/hosts`
not being used.
That specific problem was resolved in go1.22 (through [golang/go@33d4a51]), but
other limitations may still apply, and resolver ordering may not respect VPN
adaptors (such as Twingate) and queries sent through the local network adapter
instead of the VPN tunnel, resulting in DNS resolution failures;
Get "https://example.com:2376/v1.52/containers/json": dial tcp: lookup example.com: i/o timeout
This patch unsets the `netgo` option when (cross-)compiling for Windows, similar
to the patch used for the daemon (see [moby/moby@53d1b12]).
[golang/go@33d4a51]: https://github.com/golang/go/commit/33d4a5105cf2b2d549922e909e9239a48b8cefcc
[moby/moby@53d1b12]: https://github.com/moby/moby/commit/53d1b12bc014b4243e9439fc2610eb4ef863659f
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Transform `VERSION` variable if it contains a git ref.
This is the same as moby does (with "<<<" bashism removed).
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This was introduced in 9d40c7464e, which added
support for `SOURCE_DATE_EPOCH` to override the build-time.
macOS uses the BSD flavor of `date`, which does not support the `--date` option
to set a custom time.
Before this:
DISABLE_WARN_OUTSIDE_CONTAINER=1 make binary
./scripts/build/binary
date: illegal option -- -
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
After this:
DISABLE_WARN_OUTSIDE_CONTAINER=1 make binary
./scripts/build/binary
Building static docker-darwin-amd64
+ go build -o build/docker-darwin-amd64 -tags ' osusergo pkcs11' -ldflags ' -w -X "github.com/docker/cli/cli/version.GitCommit=a4b6fe16a" -X "github.com/docker/cli/cli/version.BuildTime=2022-04-06T10:57:25Z" -X "github.com/docker/cli/cli/version.Version=20.10.2-589-ga4b6fe16a.m"' -buildmode=pie github.com/docker/cli/cmd/docker
...
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When building on Fedora 36, the build failed. I suspect this is because the
rpm tools also set LDFLAGS, but with options that cannot be used;
GO_LINKMODE=dynamic
+ ./scripts/build/binary
/go/src/github.com/docker/cli ~/rpmbuild/BUILD/src
Building dynamic docker-linux-arm64
+ go build -o build/docker-linux-arm64 -tags ' pkcs11' -ldflags '-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/root/rpmbuild/BUILD/src/.package_note-docker-ce-cli-0.0.0.20220330082637.68cad50-0.fc36.aarch64.ld -w -X "github.com/docker/cli/cli/version.GitCommit=68cad50" -X "github.com/docker/cli/cli/version.BuildTime=2022-03-30T20:05:36Z" -X "github.com/docker/cli/cli/version.Version=0.0.0-20220330082637-68cad50" -X "github.com/docker/cli/cli/version.PlatformName=Docker Engine - Community"' -buildmode=pie github.com/docker/cli/cmd/docker
# github.com/docker/cli/cmd/docker
flag provided but not defined: -Wl,-z,relro
usage: link [options] main.o
This patch changes the variable we use to `GO_LDFLAGS`, taking a similar approach
as containerd, and various other projects using this name: https://grep.app/search?q=GO_LDFLAGS
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Our previous CI probably did not cross-compile for s390x and ppc64le,
and therefore did not get these errors; the scripts/build/.variables
file sets CGO_ENABLED=1 for amd64|arm64|arm|s390x architectures if
it's not set;
https://github.com/docker/cli/blob/87b8e57868adba9e189e9fb74e5bd5d189a024c8/scripts/build/.variables#L34-L46
When compiling statically with CGO enabled, we must have osusergo
enabled as well, so set it accordingly, to prevent;
#53 [linux/amd64 build 2/2] RUN --mount=type=bind,target=.,ro --mount=type=cache,target=/root/.cache --mount=from=dockercore/golang-cross:xx-sdk-extras,target=/xx-sdk,src=/xx-sdk --mount=type=tmpfs,target=cli/winresources xx-go --wrap && TARGET=/out ./scripts/build/binary && xx-verify $([ "static" = "static" ] && echo "--static") /out/docker
#53 953.6 # github.com/docker/cli/cmd/docker
#53 953.6 /usr/bin/s390x-linux-gnu-ld: /tmp/go-link-2402600021/000022.o: in function `New':
#53 953.6 /go/src/github.com/docker/cli/vendor/github.com/miekg/pkcs11/pkcs11.go:75: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
#53 953.6 /usr/bin/s390x-linux-gnu-ld: /tmp/go-link-2402600021/000018.o: in function `mygetgrouplist':
#53 953.6 /usr/local/go/src/os/user/getgrouplist_unix.go:18: warning: Using 'getgrouplist' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
#53 953.6 /usr/bin/s390x-linux-gnu-ld: /tmp/go-link-2402600021/000017.o: in function `mygetgrgid_r':
#53 953.6 /usr/local/go/src/os/user/cgo_lookup_unix.go:40: warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
#53 953.6 /usr/bin/s390x-linux-gnu-ld: /tmp/go-link-2402600021/000017.o: in function `mygetgrnam_r':
#53 953.6 /usr/local/go/src/os/user/cgo_lookup_unix.go:45: warning: Using 'getgrnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
#53 953.6 /usr/bin/s390x-linux-gnu-ld: /tmp/go-link-2402600021/000017.o: in function `mygetpwnam_r':
#53 953.6 /usr/local/go/src/os/user/cgo_lookup_unix.go:35: warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
#53 953.6 /usr/bin/s390x-linux-gnu-ld: /tmp/go-link-2402600021/000017.o: in function `mygetpwuid_r':
#53 953.6 /usr/local/go/src/os/user/cgo_lookup_unix.go:30: warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
#53 953.6 /usr/bin/s390x-linux-gnu-ld: /tmp/go-link-2402600021/000004.o: in function `_cgo_3c1cec0c9a4e_C2func_getaddrinfo':
#53 953.6 /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
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Using cross compilation toolchains that work from any platform
Adds darwin/arm64 support and bake targets. Static and dynamic
binary targets are available, both with glibc and musl.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
macOS doesn't ship with the GNU version of `date`, which
causes the command to fail if the `--rfc-3339 ns` format option
is used.
Given that we don't need the build-time with nanosecond precision,
this patch changes the format used, so that the CLI binary can be
built on the host (outside of a container);
Before this change, `make binary` would fail:
DISABLE_WARN_OUTSIDE_CONTAINER=1 make binary
WARNING: binary creates a Linux executable. Use cross for macOS or Windows.
./scripts/build/binary
make: *** [binary] Error 1
With this change, the binary can be built on the host:
DISABLE_WARN_OUTSIDE_CONTAINER=1 make binary
WARNING: binary creates a Linux executable. Use cross for macOS or Windows.
./scripts/build/binary
Building statically linked build/docker-darwin-amd64
While the previous version formatted (and parsed) the date with nanoseconds precision,
that level of precision is not actually used;
```go
func reformatDate(buildTime string) string {
t, errTime := time.Parse(time.RFC3339Nano, buildTime)
if errTime == nil {
return t.Format(time.ANSIC)
}
return buildTime
}
```
Both the old, and new input will yield the same output:
```go
fmt.Println(reformatDate("2019-12-31T13:41:44.846741804+00:00"))
// Tue Dec 31 13:41:44 2019
fmt.Println(reformatDate("2019-12-31T13:41:44Z"))
// Tue Dec 31 13:41:44 2019
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This just makes it easier to build a targeted binary for the
goos/goach/goarm version.
This of course will not work for all cases but is nice to get things
going.
Specifically cross-compiling pkcs for yubikey support requires some
extra work whichis not tackled here.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This helps to avoid circular includes, by separating the pure data out from the
actual functionality in the cli subpackage, allowing other code which is
imported to access the data.
Signed-off-by: Ian Campbell <ijc@docker.com>
The Server section of version output is now composed of an Engine
component and potentially more, based on what the /version endpoint
returns.
Signed-off-by: Tibor Vass <tibor@docker.com>
Sebastiaan van Stijn
Tianon GraviandSebastiaan van Stijn
Wenlong Zhang
Paweł Gronowski
Zhuo Zhi
CrazyMax
Brian GoffandGitHub
Tonis Tiigi
Morten Linderud
Ian Campbell
Tibor Vass
Daniel Nephin