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

Cross compilation is not working #42

Open
mavlyutov opened this issue Apr 13, 2016 · 6 comments
Open

Cross compilation is not working #42

mavlyutov opened this issue Apr 13, 2016 · 6 comments

Comments

@mavlyutov
Copy link

Hi!

I am trying to use gimme cross compilation feature by defining GIMME_OS env var.
But it seems windows and darwin builds are not affected =(
In the build log of windows branch one could find: GOOS=linux
moreover, go 1.6 with GIMME_OS=windows throws an error

$ eval "$(gimme 1.6)"
error: Missing bootstrap installation
error: Unable to compile go from git clone
error: Missing bootstrap installation
error: Unable to compile go from git clone
I don't have any idea what to do with '1.6'.
  (using type 'auto')

here's my config file:

language: go

go:
  - 1.6

env:
  - GIMME_OS=linux GIMME_ARCH=amd64
  - GIMME_OS=darwin GIMME_ARCH=amd64
  - GIMME_OS=windows GIMME_ARCH=amd64

install:
  - go get -d -v ./...

script:
  - go build -v

deploy:
  provider: releases
  api_key:
    secure: "Fx2Kx0KP ** SNIP ** DqGtN4Mqns="
  file: golagraphite_*
  skip_cleanup: true
  on:
    tags: true

build: https://travis-ci.org/mavlyutov/golagraphite/jobs/122741090

@glevand
Copy link
Contributor

glevand commented May 6, 2016

I have some fixes for this in #45.
Current gimme just tries to find an existing bootstrap, so it will fail if you didn't install one. I have a fix that also tries to find a binary bootstrap to use (gimme: Try binary bootstrap).

@seh
Copy link

seh commented May 15, 2016

I too find that none of the following Go versions will work for GIMME_OS values of "darwin" or "windows":

  • 1.6
  • 1.6.2
  • tip

The builds with GIMME_OS set to "linux" work fine for all three of those versions.
Is this supposed to work?

petemoore added a commit to taskcluster/taskcluster-worker that referenced this issue Jul 22, 2016
petemoore added a commit to taskcluster/taskcluster-worker that referenced this issue Aug 1, 2016
walac added a commit to taskcluster/taskcluster-worker that referenced this issue Aug 1, 2016
@petemoore
Copy link

In the end, this fixed it.

Since go 1.5, the standard binaries come shipped with cross-compilation support, so the trick is to just download a recent binary, and then set GOOS and GOARCH. Any values you set for GOOS and GOARCH in the env: section will get lost, thanks to gimme, so use something else, like MY_GOOS and MY_GOARCH instead, as in the link above.

petemoore added a commit to taskcluster/slugid-go that referenced this issue Aug 1, 2016
petemoore added a commit to taskcluster/livelog that referenced this issue Aug 1, 2016
petemoore added a commit to taskcluster/stateless-dns-go that referenced this issue Aug 1, 2016
petemoore added a commit to taskcluster/stateless-dns-go that referenced this issue Aug 1, 2016
petemoore added a commit to taskcluster/taskcluster-proxy that referenced this issue Aug 1, 2016
petemoore added a commit to taskcluster/taskcluster-proxy that referenced this issue Aug 1, 2016
@seh
Copy link

seh commented Aug 1, 2016

@petemoore, I read that as, "The fix for gimme not working is to not use gimme."

walac added a commit to taskcluster/taskcluster-proxy that referenced this issue Aug 1, 2016
walac added a commit to taskcluster/stateless-dns-go that referenced this issue Aug 1, 2016
walac added a commit to taskcluster/livelog that referenced this issue Aug 1, 2016
walac added a commit to taskcluster/slugid-go that referenced this issue Aug 1, 2016
@petemoore
Copy link

petemoore commented Aug 2, 2016

😃 ... so that is my workaround, yes! At least for go 1.5 onwards, where the standard binaries come shipped with cross compilation support.

jonasfj pushed a commit to taskcluster/taskcluster-worker that referenced this issue Aug 22, 2016
jonasfj pushed a commit to taskcluster/taskcluster-worker that referenced this issue Aug 22, 2016
stanislavb added a commit to tomologic/wrench that referenced this issue Jul 20, 2017
Gimme has broken cross-compilation:
travis-ci/gimme#42

Anyway golang now has cross-compilation built-in so we can just use go
build with GOOS and GOARCH environment variables.

Fixes issue where Travis released a linux binary as a darwin binary for
wrench 0.41.0
jgillich added a commit to jgillich/nixbench that referenced this issue Aug 11, 2017
@philpennock
Copy link
Contributor

If this is still happening, could someone affected please report the output of gimme --version on such a broken install?

After this bug was filed, some folks did a bunch of work on setting up cross-compilation for the bootstrap binary using $GIMME_HOSTARCH and $GIMME_HOSTOS (both automatically set by gimme, probably should not be overridden).

philpennock added a commit that referenced this issue Feb 22, 2018
ASSUMPTION: gimme's bootstrap is not being used to make a Go release
which can be copied to another system and used _there_ to build, but is
instead invoked locally to build the final version, where the final
version will be used for any cross-compilation.  Therefore we always
want to use the `HOST` variants for OS/ARCH for the bootstrap stage.

So, use the new resolution stuff to consider 1.10.x, 1.9.x or 1.8.x for
cross-compiling only, where we'll grab the latest on the branch for
future cross-compiles rather than continue with something which might
have known code-generation bugs.

And always go for the ${GIMME_HOSTOS:?}.${GIMME_HOSTARCH:?} variants.

Local testing confined to "can install a bootstrap".

Might help with issue #42.
philpennock added a commit that referenced this issue Feb 22, 2018
ASSUMPTION: gimme's bootstrap is not being used to make a Go release
which can be copied to another system and used _there_ to build, but is
instead invoked locally to build the final version, where the final
version will be used for any cross-compilation.  Therefore we always
want to use the `HOST` variants for OS/ARCH for the bootstrap stage.

So, use the new resolution stuff to consider 1.10.x, 1.9.x or 1.8.x for
cross-compiling only, where we'll grab the latest on the branch for
future cross-compiles rather than continue with something which might
have known code-generation bugs.

And always go for the ${GIMME_HOSTOS:?}.${GIMME_HOSTARCH:?} variants.

Local testing confined to "can install a bootstrap".

Might help with issue #42.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants