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/dist: list all valid combinations of GOOS and GOARCH #12270

Closed
otm opened this issue Aug 22, 2015 · 15 comments
Closed

cmd/dist: list all valid combinations of GOOS and GOARCH #12270

otm opened this issue Aug 22, 2015 · 15 comments
Assignees
Milestone

Comments

@otm
Copy link

@otm otm commented Aug 22, 2015

To easier write tooling for cross compiling it would be good to programmatically get the possible combinations of GOOS and GOARCH.

The only reference I can find is at http://golang.org/doc/install/source#environment

In addition, go help environmentonly gives examples; andgo help build and go help installdoes not mention GOOS and GOARCH.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Aug 22, 2015

I've wanted this too for the Go builders.

@bradfitz bradfitz added this to the Unplanned milestone Aug 22, 2015
@bradfitz bradfitz added the Builders label Aug 22, 2015
@bradfitz bradfitz changed the title go tool to list all valid combinations of GOOS and GOARCH cmd/dist: list all valid combinations of GOOS and GOARCH Aug 22, 2015
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Sep 3, 2015

See also my comment on https://go-review.googlesource.com/#/c/14272/ where the map of GOOS/GOARCH pairs supporting cgo is duplicated.

That could move to this internal package.

/cc @minux

@minux
Copy link
Member

@minux minux commented Sep 4, 2015

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 4, 2015

CL https://golang.org/cl/14278 mentions this issue.

@hirochachacha
Copy link
Contributor

@hirochachacha hirochachacha commented Jan 10, 2016

Hmm, I don't think the CL satisfy me.

(not tested! sorry!)
Please consider platforms: "nacl_amd64", "linux_s390"

  • Both of two are supported by go (build) command and go/build package.
  • gccgo support "linux_390", but gc doesn't.
  • gccgo and gc doesn't support "nacl_amd64".

My point is:

  • Build contexts and compiler supported contexts are different concepts.
  • Compiler supported contexts are part of build contexts.
  • Compiler supported contexts are different per implementations.

Maybe there are wrong assumptions, if so, please feel free to correct me.

Thank you.

hiro

@minux
Copy link
Member

@minux minux commented Jan 10, 2016

@hirochachacha
Copy link
Contributor

@hirochachacha hirochachacha commented Jan 10, 2016

Where is plan9?

@minux
Copy link
Member

@minux minux commented Jan 10, 2016

@hirochachacha
Copy link
Contributor

@hirochachacha hirochachacha commented Jan 10, 2016

gccgo?

@minux
Copy link
Member

@minux minux commented Jan 10, 2016

@hirochachacha
Copy link
Contributor

@hirochachacha hirochachacha commented Jan 10, 2016

And note that gc can build for any target supported, but for gccgo you actually need to build and install a separate gccgo for any platform you need.

Hmm, is this mean gccgo isn't able to cross compile? or need to compile libgo per platforms?

Anyway, I think runtime package is an appropriate place to put compiler-dependent information.

What do you think?

Thank you.

hiro

@minux
Copy link
Member

@minux minux commented Jan 10, 2016

@hirochachacha
Copy link
Contributor

@hirochachacha hirochachacha commented Jan 10, 2016

Finally, I am convinced by your suggestion.

I still think cgoEnabled should be different per implementations in go/build package.
But it's a different issue.

I also suggest cmd/api should be updated after you reaching the goal.

func defaultContexts() []*build.Context {
  switch runtime.Compiler {
  case "gc":
    return xxx // import from go tool dist list
  case "gccgo":
    return yyy // do something
  } 
}

Thank you for your kindly responses.

hiro

@gopherbot
Copy link

@gopherbot gopherbot commented Jan 19, 2016

CL https://golang.org/cl/18687 mentions this issue.

gopherbot pushed a commit that referenced this issue Jan 19, 2016
Both mips64 architectures share the same runtime/rt0 file, so
we have to hardcode them in buildall.bash.

Ideally we should have cmd/dist report all supported platforms,
see #12270.

Change-Id: I08ce35cfe0a831af5e1e8255b305efd38386fa52
Reviewed-on: https://go-review.googlesource.com/18687
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
gopherbot pushed a commit that referenced this issue Feb 24, 2016
This reduces the amount of duplication. Now there is only one list
of platforms supporting cgo.

Update #12270.

Change-Id: I5dcd55cb6be7c5bb6ce560383c71d90ab1189dc9
Reviewed-on: https://go-review.googlesource.com/14278
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@minux minux self-assigned this Feb 24, 2016
@gopherbot
Copy link

@gopherbot gopherbot commented Feb 24, 2016

CL https://golang.org/cl/19837 mentions this issue.

@gopherbot gopherbot closed this in c3ecded Feb 24, 2016
@golang golang locked and limited conversation to collaborators Feb 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
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.