-
Notifications
You must be signed in to change notification settings - Fork 280
Figure out a way to support arm v5/6/7 non/multiarch #6
Comments
the current arm is v? btw, really hope can do in one shell, I am good at shell, maybe I can be some help. |
v5 Definitely needs separate docker containers as both Go installations as well as C cross compilation toolkits conflict each other. |
what about put go in different directories? |
Are you sure it's v5? When I use xgo to cross compile, I get:
|
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? |
I think it's because here: |
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. |
Yeah, it was the missing GOARM=5. I'll submit a PR. |
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:) ) |
Submitted. Also threw in another one to bump up to 1.4. |
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 :) |
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?
Or the failing one
|
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 |
Yep, OSX crosscompile happily works for me, though I'm on an i7, so wouldn't expect to see that error. |
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). |
Hi. I ran into the same |
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>
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 distributionsxgo-1.3.3-arm-v5
,xgo-1.3.3-arm-v6
,xgo-1.3.3-arm-v7
for ARM specific onesThe text was updated successfully, but these errors were encountered: