Bug 1017186 - docker not built with proper build flags for version
docker not built with proper build flags for version
Product: Fedora
Classification: Fedora
Component: docker-io (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lokesh Mandvekar
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-10-09 07:57 EDT by Matthew Miller
Modified: 2014-07-01 18:59 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-03 08:14:59 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2013-10-09 07:57:55 EDT
$ docker -v
Docker version , build 

Should instead say something like

$ docker -v
Docker version 0.6.1, build 5105263

This is because we need to pass in that information at build time -- the upstream scripts use something like

GITCOMMIT=$(git rev-parse --short HEAD)
if [ -n "$(git status --porcelain)" ]; then

Although we should check with upstream, I think maybe we should use %{release} insteaed of $GITCOMMIT.
Comment 1 Marek Goldmann 2013-10-17 11:10:30 EDT
I'm seeing same issue in docker-io-0.7-0.7.rc3.fc21.
Comment 2 Matthew Miller 2013-10-17 11:28:33 EDT
I was hoping for some feedback from upstream but haven't heard. In the meantime, I think we should use


so that it comes out like 

 Docker version 0.6.3, build b0a49a3/4.fc20
Comment 3 Matthew Miller 2013-10-22 12:58:51 EDT
Docker upstream has confirmed that the above is good.


LDFLAGS="-X main.GITCOMMIT %{shortcommit}/%{release} -X main.VERSION %{version} -w"


  -ldflags "$LDFLAGS"

to the 'go build' line.

This also adds -w, to disable building with debugging in the executable which isn't working with debuginfo anyway.

I didn't include -d -- that should only go on the dockerinit build line. (It isn't, currently.)
Comment 4 Lokesh Mandvekar 2013-10-22 14:24:42 EDT

adding -d to dockerinit build gives this:

# github.com/dotcloud/docker/dockerinit
/usr/lib64/golang/pkg/tool/linux_amd64/6l: $WORK/net.a(_cgo_import.6): cannot use dynamic imports with -d flag
/usr/lib64/golang/pkg/tool/linux_amd64/6l: $WORK/runtime/cgo.a(_cgo_import.6): cannot use dynamic imports with -d
sigprocmask(0): not defined
fwrite(0): not defined
stderr(0): not defined
sigfillset(0): not defined
setenv(0): not defined
fprintf(0): not defined
abort(0): not defined
malloc(0): not defined
pthread_attr_init(0): not defined
strerror(0): not defined
pthread_create(0): not defined
pthread_attr_getstacksize(0): not defined
pthread_attr_destroy(0): not defined
free(0): not defined
__errno_location(0): not defined
.got(0): not defined
getaddrinfo(0): not defined
gai_strerror(0): not defined
freeaddrinfo(0): not defined
too many errors
error: Bad exit status from /var/tmp/rpm-tmp.u6baml (%build)
Comment 5 Alexander Larsson 2013-10-24 05:32:11 EDT
I think with go 1.1 you can't build a static binary that uses the "net" module without building a version of go with cgo completely disabled. In go 1.2 this will be possible with the "-tags netgo" argument to go.

I think shipping a dynamic dockerinit that links to libc (but nothing else) will have to do for now unfortunately.
Comment 6 Marek Goldmann 2013-12-03 08:14:59 EST
This is now fixed in 0.7.0-14 or similar, closing.

$ docker -v
Docker version 0.7.0, build 0ff9bc1/0.7.0

Note You need to log in before you can comment on or make changes to this bug.