Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build id varies from parallelism #42159

Closed
bmwiedemann opened this issue Oct 23, 2020 · 6 comments
Closed

build id varies from parallelism #42159

bmwiedemann opened this issue Oct 23, 2020 · 6 comments

Comments

@bmwiedemann
Copy link

@bmwiedemann bmwiedemann commented Oct 23, 2020

While working on reproducible builds for openSUSE, I found that
various binaries in our packages varied in the .note.go.buildid ELF section when comparing with a 1-core-VM build.

What version of Go are you using (go version)?

$ go version
go version go1.14.10 linux/amd64

occurred since 1.10

Does this issue reproduce with the latest release?

No. It does not occur with 1.15.3
maybe related to
c5f6920
a3e965c

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/abuild/.cache/go-build"
GOENV="/home/abuild/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/abuild/rpmbuild/BUILD/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib64/go/1.14"
GOSUMDB="sum.golang.org"
GOTMPDIR=""  
GOTOOLDIR="/usr/lib64/go/1.14/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/abuild/rpmbuild/BUILD/go/src/github.com/marguerite/rime-plum-go/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build964245478=/tmp/go-build -gno-record-gcc-switches"

What did you do?

on openSUSE or Debian do

osc co openSUSE:Factory/brise && cd $_
for N in 1 3 ; do
    osc build --keep-pkg=RPMS.$N -j$N --vm-type=kvm --clean --noservice
    unrpm RPMS.$N/rime-*.x86_64.rpm
    objdump -s usr/bin/rime-plum > $N.objdump
done
diff -u {1,3}.objdump

What did you expect to see?

reproducible build results

What did you see instead?

@@ -521555,14 +521555,14 @@
  400ff4 7838362d 36342e73 6f2e3200           x86-64.so.2.
 Contents of section .note.go.buildid:
  400f80 04000000 53000000 04000000 476f0000  ....S.......Go..
- 400f90 614b4c68 6d773677 4d67764f 4a356465  aKLhmw6wMgvOJ5de
- 400fa0 4a59704f 2f747955 2d527264 6b665956  JYpO/tyU-RrdkfYV
+ 400f90 57337966 30594f37 54527039 616d6871  W3yf0YO7TRp9amhq
+ 400fa0 542d554e 2f747955 2d527264 6b665956  T-UN/tyU-RrdkfYV
  400fb0 32466e69 4c33762d 712f3069 71317642  2FniL3v-q/0iq1vB
- 400fc0 2d706378 4a6e6b4b 5a4b4a76 396c2f44  -pcxJnkKZKJv9l/D
- 400fd0 75587270 72416372 2d544766 6f5a654d  uXrprAcr-TGfoZeM
- 400fe0 39334600                             93F.
+ 400fc0 2d706378 4a6e6b4b 5a4b4a76 396c2f4a  -pcxJnkKZKJv9l/J
+ 400fd0 344f3973 364e396e 78357471 776b4d4f  4O9s6N9nx5tqwkMO
+ 400fe0 72555600                             rUV.
 Contents of section .gnu_debuglink:
  0000 72696d65 2d706c75 6d2d302e 33392b67  rime-plum-0.39+g
  0010 69743230 31393031 32302e38 64356263  it20190120.8d5bc
  0020 32652d30 2e783836 5f36342e 64656275  2e-0.x86_64.debu
- 0030 67000000 76911053                    g...v..S                           
+ 0030 67000000 06a5d277                    g......w
@ALTree
Copy link
Member

@ALTree ALTree commented Oct 23, 2020

Does passing -ldflags=-buildid= (i.e. setting -buildid to an empty string) fix the issue? If yes, this is known and the workaround is that one.

@mvdan
Copy link
Member

@mvdan mvdan commented Oct 23, 2020

I assume upgrading to 1.15.3 would also fix the problem, as I can only find closed issues about this problem.

@bmwiedemann
Copy link
Author

@bmwiedemann bmwiedemann commented Oct 23, 2020

yes and yes. Would backporting the fixes to 1.14.x be an option?

@ALTree
Copy link
Member

@ALTree ALTree commented Oct 23, 2020

I doubt it. From the Minor Releases policy:

Our default decision should always be to not backport, but fixes for security issues, serious problems with no workaround, and documentation fixes are backported to the most recent two release branches, if applicable to that branch.

This doesn't qualify because it has a very simple workaround.

@ALTree
Copy link
Member

@ALTree ALTree commented Oct 24, 2020

Since this is known, fixed at latest, and unlikely to be backported, I'm closing here.

@ALTree ALTree closed this Oct 24, 2020
@bmwiedemann
Copy link
Author

@bmwiedemann bmwiedemann commented Oct 25, 2020

Fine with me. Soon 1.14 will be obsolete and forgotten.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.