Navigation Menu

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: darwin/arm builders broken by content-based build CL #22509

Closed
rsc opened this issue Oct 31, 2017 · 8 comments
Closed

build: darwin/arm builders broken by content-based build CL #22509

rsc opened this issue Oct 31, 2017 · 8 comments
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented Oct 31, 2017

Looks like I broke the darwin/arm builders with my CL 73212. Investigating.

The log at https://build.golang.org/log/83cd0cb12afd4ff5069c6a9a72b124e02d21127c makes it look like there are two different make.bash runs, which maybe is part of the problem.

/cc @eliasnaur @crawshaw

@rsc rsc added this to the Go1.10 milestone Oct 31, 2017
@eliasnaur
Copy link
Contributor

eliasnaur commented Oct 31, 2017

Thanks for putting up with the difficult mobile os'es. Off the top of my head:

  • iostest.bash runs make.bash and then all.bash.
  • cmd/dist test (still) rebuilds runtime/cgo with the lldb tag. I remember that you meant to handle this at some point.

Not sure if any is relevant.

@rsc
Copy link
Contributor Author

rsc commented Oct 31, 2017

I can reproduce locally without an ios device. One unrelated point: iostest.bash runs all.bash --no-rebuild but that's not a thing. all.bash always rebuilds; perhaps that was supposed to be run.bash --no-rebuild.

The root cause appears to be that when you do a cross-compile build it looks like the CC_FOR_TARGET gets recorded as the default $CC for both host and target builds, so the host binaries look out of date during the run.bash half (because they were not built with CC=$CC_FOR_TARGET).

Related to #8161 in part.

Update: iostest.bash says --no-clean not --no-rebuild so ignore my comment above.

@rsc
Copy link
Contributor Author

rsc commented Oct 31, 2017

Off to a meeting but will keep at this later.

@gopherbot
Copy link

Change https://golang.org/cl/76018 mentions this issue: cmd/dist, cmd/cgo, cmd/go: allow per-goos/goarch default CC

@gopherbot
Copy link

Change https://golang.org/cl/76020 mentions this issue: cmd/dist: do not reinstall runtime/cgo with -tags lldb on ios builders

gopherbot pushed a commit that referenced this issue Nov 6, 2017
Even though cmd/dist has historically distinguished "CC for gohostos/gohostarch"
from "CC for target goos/goarch", it has not recorded that distinction
for later use by cmd/cgo and cmd/go. Now that content-based staleness
includes the CC setting in the decision about when to rebuild packages,
the go command needs to know the details of which CC to use when.
Otherwise lots of things look out of date and (worse) may be rebuilt with
the wrong CC.

A related issue is that users may want to be able to build a toolchain
capable of cross-compiling for two different non-host targets, and
to date we've required that CC_FOR_TARGET apply to both.
This CL introduces CC_FOR_${GOOS}_${GOARCH}, so that you can
(for example) set CC_FOR_linux_arm and CC_FOR_linux_arm64
separately on a linux/ppc64 host and be able to cross-compile to
either arm or arm64 with the right toolchain.

Fixes #8161.
Half of a fix for #22509.

Change-Id: I7a43769f39d859f659d31bc96980918ba102fb83
Reviewed-on: https://go-review.googlesource.com/76018
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
@rsc
Copy link
Contributor Author

rsc commented Nov 6, 2017

Supposed to be fixed now. We will see.

@rsc
Copy link
Contributor Author

rsc commented Nov 7, 2017

@eliasnaur I did fix the failure we were seeing. Now we are seeing different failures. I am not sure what to make of them. Can you take a look and maybe file a new issue if you can see more?

@eliasnaur
Copy link
Contributor

Thanks. It looks unrelated to the content-based caching. #22612

@golang golang locked and limited conversation to collaborators Nov 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants