-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go, cmd/cgo: repeatable builds with Clang 3.8 #15405
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
Comments
This is unfortunate but not critical for the release. |
Postponing to 1.8. |
It sounds like we just need to wait for clang and gcc to fix their reproducible build support. clang Support for -fdebug-prefix-map was added Oct 2015. Clang 3.7.0 was released Sep 2015, Clang 3.7.1 was released Jan 2016, and Clang 3.8 was released Mar 2016. My guess is the change may have missed the Clang 3.7 point release but was likely in Clang 3.8. Without detecting support for the flag, the test is skipped. This is why we don't see failures before Clang 3.8. The linux-amd64-clang gomote image is using Clang 3.5, so we don't test this case on the builder. @bradfitz, is it possible to update to a newer clang? Latest is 3.9.0 released Sep 2 2016. http://llvm.org/releases/ gcc Support for -fdebug-prefix-map is more widespread, but some versions don't quite work. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69821 shows that while -fdebug-prefix-map did the right thing to the debug symbols, gcc then included that option in the DW_AT_producer field of the dwarf. If the goal of -fdebug-prefix-map=old=new is to eliminate the string "old" from the binary, writing down that option into the binary defeats the purpose. The bug entry says the target milestone is gcc 6 and the discussion there sounds like the decision was not to backport to gcc 5. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819176, the Debian entry for this bug, suggests it is fixed in Debian's gcc 5.4.0. It is unclear whether that means the fix is only in Debian's copy or is upstream. It's unclear to me when DW_AT_producer first started recording the whole command line. Obviously the tests do pass on our gcc builders, and I confirmed that (unlike the clang builder) the gcc on the builder does support the flag, so the test should be running. Perhaps gcc 4.3 had a related problem. |
Also #5170. |
CL https://golang.org/cl/34675 mentions this issue. |
FreeBSD 11 or above uses clang-3.6 or higher by default. Updates #15405. Change-Id: If49ce298130165f9e1525c7fd0fd5aa39099ad53 Reviewed-on: https://go-review.googlesource.com/34675 Reviewed-by: Brad Fitzpatrick <[email protected]> Run-TryBot: Brad Fitzpatrick <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>
This is working for me:
The builders are on clang 3.9 and it's working there too. Going to assume this is now fixed and that the problem before was that either the specific clang 3.8 being used didn't have -fdebug-prefix-map or did not implement it correctly. |
Please answer these questions before submitting your issue. Thanks!
go version
)?go version devel +f8fc371 Thu Apr 21 17:04:01 2016 +0000 linux/amd64
(but
GOROOT_BOOTSTRAP
is set to an installation ofgo1.6.2
)go env
)?Attempted to build
master
branch of Go (currently HEAD is at 40f1d0c )(more specifically:
./all.bash
within thesrc
directory)No errors.
An error within the tests, namely:
Notes
clang
, this error is not thrown (fails at cmd/cgo: ThreadSanitizer barks about data races in all.bash #14602, so not sure if issue is present)clang-3.6
, this error is not thrown (not sure why not, but some things are disabled with older clang and newer kernel (4.3))clang-3.8
, this error is thrown (but cmd/cgo: ThreadSanitizer barks about data races in all.bash #14602 is "fixed").When running
CGO_ENABLED=0
, all errors go away (makes sense).The text was updated successfully, but these errors were encountered: