Skip to content
This repository has been archived by the owner on Feb 7, 2022. It is now read-only.

Figure out a way to support arm v5/6/7 non/multiarch #6

Open
karalabe opened this issue Oct 3, 2014 · 16 comments
Open

Figure out a way to support arm v5/6/7 non/multiarch #6

karalabe opened this issue Oct 3, 2014 · 16 comments

Comments

@karalabe
Copy link
Owner

karalabe commented Oct 3, 2014

There is a lot of different ways to compile an arm code, the end result being architecture and distribution specific. Since it's kind of a time bomb to support only one type and hope for the best, xgo should be extended somehow to support building all arm types. However, since they are conflicting packages, these will probably need their own separate dockerfiles. So beside version specific containers, there will probably also be arm specific ones.

Something along the lines of:

  • xgo-1.3.3 for the official Go distributions
  • xgo-1.3.3-arm-v5, xgo-1.3.3-arm-v6, xgo-1.3.3-arm-v7 for ARM specific ones
@codeskyblue
Copy link

the current arm is v? btw, really hope can do in one shell, I am good at shell, maybe I can be some help.

@karalabe
Copy link
Owner Author

karalabe commented Oct 4, 2014

v5

Definitely needs separate docker containers as both Go installations as well as C cross compilation toolkits conflict each other.

@codeskyblue
Copy link

what about put go in different directories?

@hasty
Copy link

hasty commented Dec 15, 2014

Are you sure it's v5? When I use xgo to cross compile, I get:

 runtime: this CPU has no floating point hardware, so it cannot run this GOARM=6 binary. Recompile using GOARM=5.

@karalabe
Copy link
Owner Author

That's a tad odd. I am compiling with Dave Cheney's arm tarballs from here (1.3.3 for now), as speced in the dockerfile. Could you provide the import path of the package you are building so I could debug it?

@hasty
Copy link

hasty commented Dec 15, 2014

I think it's because here:
https://github.com/karalabe/xgo/blob/master/docker/base/Dockerfile#L114
you're not setting GOARM=5, and so it's using the default GOARM=6

@hasty
Copy link

hasty commented Dec 16, 2014

And here's a simple test package that demonstrates the problem. Uses mattn's SQLite wrapper, which requires CGO, and just keeps inserting rows in a test db and reporting how many are in there.

https://github.com/hasty/go-sqlite-test

@hasty
Copy link

hasty commented Dec 16, 2014

Yeah, it was the missing GOARM=5. I'll submit a PR.

@karalabe
Copy link
Owner Author

Good catch. I am primarily using xgo to cross compile Iris, and I didn't have such problems, alas, Iris has CGO only windows and osx side, but on Linux is pure Go. I'm guessing that's why I got away with the bug :) Send the PR and I'll merge it (if it doesn't break iris on my rpi O:) )

@hasty
Copy link

hasty commented Dec 16, 2014

Submitted. Also threw in another one to bump up to 1.4.

@karalabe
Copy link
Owner Author

Cool, both. I'll merge them, do some tests locally too and on the docker registry too and if all works, I'll push an announce on the golang nuts list :)

@karalabe
Copy link
Owner Author

I've merged your prs, thanks a million :) I've also found a subtle bug where platform dependent dependencies weren't being pulled in. Fixed that also.

Now the odd thing is, that everything works perfectly on my desktop, but osx cross compilation fails on my laptop. Which is very annoying, given that both runs the same OS, version, Go, docker and I've dumped all images and pulled fresh ones on both. Yet still, one runs always perfectly, the other always fails, returning an annoying Exit status 132 error (gr8, thx).

Could you eventually verify that everything works on your end?

> xgo -go 1.4 github.com/project-iris/iris
[...]
Moving binaries to host...

Or the failing one

> xgo -go 1.4 github.com/project-iris/iris
[...]
Compiling for darwin/amd64...
2014/12/17 17:36:38 Failed to cross compile package: exit status 132.

@karalabe
Copy link
Owner Author

After debugging a bit, it seams that the osxcross-env fails with an Illegal instruction. A wild hunch is that the docker registry compiles in on a relatively modern CPU, and my Core2 laptop doesn't support some instruction set. Which is imho a bit disappointing, as this will mean that docker containers can randomly blow up from one day to the next.

Yep: moby/moby#9003

@hasty
Copy link

hasty commented Dec 17, 2014

Yep, OSX crosscompile happily works for me, though I'm on an i7, so wouldn't expect to see that error.

@karalabe
Copy link
Owner Author

Thanks for the confirmation! At least the problem is easy-ish to fix, just have to decide whether to fix it or not (i.e. do I want to force Core2 or should we look to the future).

@jnslxndr
Copy link

jnslxndr commented Mar 6, 2015

Hi. I ran into the same Illegal Instruction issue as well. It was fixable by supplying a new OSX SDK (10.10, compiled with min-version 10.6 though). I also made it available for download. What is the best way to submit a patch to the Dockerfile (base). Sorry i have to ask, as i am quite new to Docker…

kolaente pushed a commit to kolaente/xgo that referenced this issue May 22, 2019
admpub pushed a commit to admpub/xgo that referenced this issue Nov 27, 2021
Bumps [crazy-max/ghaction-docker-login](https://github.com/crazy-max/ghaction-docker-login) from v1.1.0 to v1.1.1.
- [Release notes](https://github.com/crazy-max/ghaction-docker-login/releases)
- [Changelog](https://github.com/crazy-max/ghaction-docker-login/blob/master/CHANGELOG.md)
- [Commits](docker/login-action@v1.1.0...ef43051)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
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

4 participants