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

cmd/compile: fatal error: textflag.h: No such file or directory #40855

Closed
spackard opened this issue Aug 18, 2020 · 8 comments
Closed

cmd/compile: fatal error: textflag.h: No such file or directory #40855

spackard opened this issue Aug 18, 2020 · 8 comments
Labels

Comments

@spackard
Copy link

@spackard spackard commented Aug 18, 2020

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

Compiling 1.15 release source code using GCC 9.3 gccgo

Does this issue reproduce with the latest release?

Yes

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

linux amd64

What did you do?

Attempting to build the 1.15 release using GCC 9.3 gccgo fails with:

GOOS=linux GOARCH=amd64 \
GOROOT=/tmp/go-1.15 \
GOROOT_FINAL=/opt/go-1.15 \
GOROOT_BOOTSTRAP=/opt/go \
GCCGO=gccgo \
./make.bash
Building Go cmd/dist using /opt/go. (go1.12.2 gccgo (9.3.0-2+b20200423T09000618) 9.3.0 linux/amd64)
Building Go toolchain1 using /opt/go.
# bootstrap/cmd/compile/internal/ssa
cmd/compile/internal/ssa/flags_amd64_test.s:11:10: fatal error: textflag.h: No such file or directory
   11 | #include "textflag.h"
      |          ^~~~~~~~~~~~
compilation terminated.

What did you expect to see?

Successful build

What did you see instead?

Failed build

Per #30771 (comment), we want to avoid having to drag along older versions of gc just to bootstrap the latest release tarball.

@martisch
Copy link
Contributor

@martisch martisch commented Aug 18, 2020

Im not sure bootstrapping gc go with gccgo is supported. Bootstrapping gc go with newer versions of gc go is supported (up from go 1.4).

At least if it is supported (or will be) we should have a builder or tests for this as I dont think those are setup currently.

/cc @ianlancetaylor

@spackard
Copy link
Author

@spackard spackard commented Aug 18, 2020

You have documentation claiming it is supported: https://golang.org/doc/install/source#bootstrapFromGccgo

It's worked for every release of go so far, sans go 1.12 as linked in #30771 which was fixed for the 1.13 release (we backported the patch internally).

@martisch
Copy link
Contributor

@martisch martisch commented Aug 18, 2020

You have documentation claiming it is supported: https://golang.org/doc/install/source#bootstrapFromGccgo

Thanks for pointing that out. I open another ticket to investigate addition of build testers to make sure this is checked and not getting accidentially broken.

@martisch martisch added NeedsFix and removed NeedsDecision labels Aug 18, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Aug 18, 2020

Change https://golang.org/cl/249018 mentions this issue: cmd/dist: ignore _test.s files in bootstrap

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Aug 18, 2020

Does the CL above fix this? Thanks.

@spackard
Copy link
Author

@spackard spackard commented Aug 18, 2020

Yes, that CL does resolve the issue. Thanks.

@spackard
Copy link
Author

@spackard spackard commented Aug 19, 2020

Any chance this will be backported to 1.15? We can carry the patch internally until 1.16 is released, but that's not ideal. Thanks for the quick turnaround!

@ALTree
Copy link
Member

@ALTree ALTree commented Aug 19, 2020

@spackard The project policy on backporting is:

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.

(from https://github.com/golang/go/wiki/MinorReleases).

In this case, your best bet is the "serious problems with no workaround" option. It may help with the backporting decision if you could explain why the issue at hand has no feasible workaround. If I have understood #30771 correctly, we have a precedent (and we didn't backport, in that case).

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
5 participants
You can’t perform that action at this time.