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/go: when compiling with gccgo uses go tool's ReleaseTags, not gccgo's #8851

Open
mwhudson opened this Issue Oct 1, 2014 · 12 comments

Comments

Projects
None yet
7 participants
@mwhudson
Contributor

mwhudson commented Oct 1, 2014

What steps reproduce the problem?

1. Install a version of go (such as 1.3) and a version of gccgo that implements a
different version of the language (such as gccgo 4.9, which implements go 1.2)
2. Try to build a package that uses the go1.3 build tag to conditionally support go 1.3
features (for example, https://github.com/docker/docker/tree/master/pkg/pools )

What happened?

The go tool attempts to compile the file with the go1.3 built tag with gccgo, and this
fails.

What should have happened instead?

It should have compiled the file with the !go1.3 build tag instead.

Please provide any additional information below.

The cause for this is pretty clear: the go tool uses the ReleaseTags from the go/build
package of the standard library that the go tool was built against, which is not
necessarily the same as the one the compiler being invoked.  This could be fixed by
compiling a little program that prints out go/build.Default.ReleaseTags and using those
in the go tool

There are other places where go tool and gccgo compiler have different views of things,
but this is the one that is biting me today.
@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Oct 1, 2014

Comment 1:

Labels changed: added repo-main, release-go1.5.

@mwhudson

This comment has been minimized.

Contributor

mwhudson commented Oct 1, 2014

Comment 2:

Here is a fairly terrible patch (which is why it's in a pastebin and not a CL):
http://paste.ubuntu.com/8475820/ 
It seems to work.  Does this approach have any merit?  It would make using -compiler
gccgo to cross compile basically impossible, not sure what to do there (I mean, a
correct fix might be for gccgo to grow a "-dumpbuildcontextinfo" flag?)
@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Oct 2, 2014

Comment 3:

Perhaps when the -compiler option is used the go tool should not use the default release
tags at all.  They can still be specified using the -tags option.
@mwhudson

This comment has been minimized.

Contributor

mwhudson commented Oct 2, 2014

Comment 4:

That would be a lot cleaner, certainly.
@pcc

This comment has been minimized.

Contributor

pcc commented Nov 3, 2014

Comment 5:

That would certainly be simpler for the implementation, but it puts a significant burden
on the user to keep track of which versions of Go the compiler supports, and supply the
correct set of tags at every invocation. I would also consider it to be a regression in
functionality; at least, at the moment, the set of release tags is roughly correct.
I would much prefer if the "go" tool obtained this information automatically from the
compiler. I propose that "go" request a set of compiler tags from "gccgo" toolchains by
executing "$GCCGO -dumpgotags" and reading the tags from stdout. For backwards
compatibility with existing versions of gccgo/llgo, the "go" tool's built-in set of
compiler tags would continue to be used if the exit status is non-zero.
https://golang.org/cl/167080043 implements this, and I will mail it after the
go1.4 release.
@pcc

This comment has been minimized.

Contributor

pcc commented Nov 6, 2014

Comment 6:

https://golang.org/cl/148770043/ is another issue that came up as a result of
this version skew.

@mwhudson mwhudson added new labels Nov 6, 2014

@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014

@rsc rsc removed the repo-main label Apr 14, 2015

@rsc

This comment has been minimized.

Contributor

rsc commented Apr 20, 2015

Why do gccgo and llgo insist on trying to use a gc-toolchain-compiled go command in the first place? If you are using those compilers you should be using a go command built by them, and then the release tags will be right. All the complexity here seems misguided.

@mwhudson

This comment has been minimized.

Contributor

mwhudson commented Apr 20, 2015

Well indeed, that's become both clearer and easier over the last few months, so I think this issue can be closed.

@mwhudson mwhudson closed this Apr 20, 2015

@mdempsky

This comment has been minimized.

Member

mdempsky commented Apr 20, 2015

If users should always use a "go" tool built by the corresponding compiler, does the -compiler flag have any use still?

@rsc

This comment has been minimized.

Contributor

rsc commented Apr 21, 2015

I talked to @ianlancetaylor about this, and he pointed out that it is convenient for users to have one go command in their binary and be able to use the -compiler flag to flip between them for building their own code (the go command doesn't know anything about the gccgo standard library; this is only about $GOPATH).

Given that, I do believe that as long as we have the -compiler we might as well get the release tags right. Ian and I talked about having a $GCCGOTAGS, but on reflection I don't think that's quite right either. Can we give gccgo and llgo the same option that means "print the Go release tags to use" and then just ask them, at roughly the same time we consult $GCCGO?

This is actually close to what comment 2 suggested, but a built-in option seems much better than compiling and running a whole Go program.

@rsc rsc reopened this Apr 21, 2015

@rsc

This comment has been minimized.

Contributor

rsc commented Jun 29, 2015

Too late for Go 1.5.

@rsc rsc modified the milestones: Unplanned, Go1.5 Jun 29, 2015

@laboger

This comment has been minimized.

Contributor

laboger commented Sep 8, 2015

There are other issues or missing function related to the use of the -compiler option on the go tool.

  • information from 'go version' refers to the compiler used to build the go tool, not the compiler being used to build with, which is what you really care about
  • trying to do cross compiles with the compiler option won't work
  • allowing any go tool to be able to compile using any other existing go compiler, no matter how old would be difficult
  • ..... I'm sure there are others

Seems like it would be better just to drop support for the -compiler option.

If that was done then copies of the go tools for alternate compilers could be provided with distinct names, something like go.gccgo and go.llgo so it was clear which ones were being used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment