Bug 1017186 - docker not built with proper build flags for version
Summary: docker not built with proper build flags for version
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: docker-io
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lokesh Mandvekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-09 11:57 UTC by Matthew Miller
Modified: 2014-07-01 22:59 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-03 13:14:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Matthew Miller 2013-10-09 11:57:55 UTC
$ 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


VERSION=$(cat ./VERSION)
GITCOMMIT=$(git rev-parse --short HEAD)
if [ -n "$(git status --porcelain)" ]; then
GITCOMMIT="$GITCOMMIT-dirty"
fi
LDFLAGS="-X main.GITCOMMIT $GITCOMMIT -X main.VERSION $VERSION -d -w"

Although we should check with upstream, I think maybe we should use %{release} insteaed of $GITCOMMIT.

Comment 1 Marek Goldmann 2013-10-17 15:10:30 UTC
I'm seeing same issue in docker-io-0.7-0.7.rc3.fc21.

Comment 2 Matthew Miller 2013-10-17 15:28:33 UTC
I was hoping for some feedback from upstream but haven't heard. In the meantime, I think we should use


   $GITCOMIIT/%{release}

so that it comes out like 

 Docker version 0.6.3, build b0a49a3/4.fc20

Comment 3 Matthew Miller 2013-10-22 16:58:51 UTC
Docker upstream has confirmed that the above is good.

So:

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

add 

  -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 18:24:42 UTC
Alex:

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
+flag
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 09:32:11 UTC
Lokesh:
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 13:14:59 UTC
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.