Closed bradfitz closed 8 years ago
so this (gcc-s390x-linux-gnu) is unfortunately only in stretch/sid/experimental https://packages.debian.org/search?keywords=gcc-s390x-linux-gnu
On Wed, Jul 20, 2016 at 10:51 AM, Brad Fitzpatrick <notifications@github.com
wrote:
This bug is about
1) how to cross-compile s390x release binaries for x/build/cmd/release 2) hosting said binaries on golang.org/dl (but only after we've figured out (1)
@jfrazelle https://github.com/jfrazelle had mentioned CC=gcc-5-s390x-linux-gnu. There a Debian package for that? We want to be able to build s390x binaries on linux-amd64. (All other release builds are built + tested on either native hardware or VMs, but we'll have to stop at just make.bash for s390x).
As for (2), we briefly discussed having a section or column to denote which builds are at which support status. Let's defer that discussion until we have (1) figured out.
/cc @billotosyr https://github.com/billotosyr, @adg https://github.com/adg, @broady https://github.com/broady
β You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/16443, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYNbDj4gkH-ezRFTROIkJyPUv2qoMj9ks5qXjX8gaJpZM4JQ2_8 .
Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3
That's fine. We can build it in a bleeding-edge-Debian container.
If we cross compile s390 binary, why not also crosscompile and provide downloads for other Linux ports as well? MIPS and PPC come to mind.
Even simpler, we could do a nocgo release, and document how the user could rebuild the choir using packages once unpacked and before installation. This post-unpack rebuild also allow the user to change the embedded GOROOT.
Can I please volunteer as tribute to figure out MIPS cross compilation, also fwiw I've played w Power cross compiling as well
On Wednesday, July 20, 2016, Minux Ma notifications@github.com wrote:
If we cross compile s390 binary, why not also crosscompile and provide downloads for other Linux ports as well? MIPS and PPC come to mind.
Even simpler, we could do a nocgo release, and document how the user could rebuild the choir using packages once unpacked and before installation. This post-unpack rebuild also allow the user to change the embedded GOROOT.
β You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/16443#issuecomment-234071189, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYNbP6hafL2iOlAqz8ya1oviCCNY8Hiks5qXoSbgaJpZM4JQ2_8 .
Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3
If we do end up cross-compiling, we should still run the tests on a real machine against the cross-compiled version.
@billotosyr is IBM able to provide access to that?
@broady, the idea is we'll only run cmd/release
at a hash which has already passed on the dashboard for s390x.
Now that 1.7 is out, is it possible to nudge this issue forward? Thx...
I'm still waiting for somebody to give me a Docker recipe for building these things.
@jfrazelle had volunteered?
On it!
CL https://golang.org/cl/27242 mentions this issue.
Can this be moved to the next step? Thx.
I tried to deploy this, but it doesn't work and I failed to figure out why.
CL was https://go-review.googlesource.com/c/28172/
/cc @evandbrown @jfrazelle
maybe i am missing something that is needed for systemd in the container? thats how these run right... i will try some things locally to see
There's no systemd in these containers.
See x/build/env/linux-x86-std-kube/Dockerfile
for a model. These run in Kubernetes.
oh i know what it is ill make a CL, facepalm
CL https://golang.org/cl/28172 mentions this issue.
Can somebody with s390x verify that this build works: https://storage.googleapis.com/go-builder-data/go.devel.linux-s390x.tar.gz.TMP ?
And can somebody review https://go-review.googlesource.com/28172 ? The tarball above was generated with cmd/release from that CL.
Given that we have cross compiling infrastructure in place, could we also host tarballs for other supported Linux architectures? arm64/ppc64/ppc64le/mips64 and mips64le.
None of them can be easily bootstrapped from C without using another architecture. (There is a route for ppc64/ppc64le, but it's very tedious.)
@minux, I suppose. If we flag the experimental ones as experimental loudly on our downloads page.
On 31 August 2016 at 12:08, Brad Fitzpatrick notifications@github.com wrote:
Can somebody with s390x verify that this build works: https://storage.googleapis.com/go-builder-data/go.devel. linux-s390x.tar.gz.TMP ?
I downloaded it, unpacked it and "GOROOT=$(pwd) ./bin/go test -short runtime" passes, enough?
@mwhudson, can you confirm that cgo works? Maybe just that os/user tests pass without skips? (since os/user uses cgo)
On 31 August 2016 at 13:34, Brad Fitzpatrick notifications@github.com wrote:
@mwhudson https://github.com/mwhudson, can you confirm that cgo works? Maybe just that os/user tests pass without skips? (since os/user uses cgo)
Yeah, that works. I also ran "./bin/go tool dist test" and everything passed apart from the API check (because there is no src/cmd/api in the tarball...)
Cheers, mwh
This tarball worked fine for me. I did have to export CC=gcc on systems other than Ubuntu, otherwise cgo would give me the error 'exec: "s390x-linux-gnu-gcc": executable file not found in $PATH'. This is only a minor nit, so please feel free to publish the tarball. Thank you very much for taking care of this!!
Assigning to @broady at this point, since cmd/release now supports it. Chris, maybe you can put up the s390x binaries tomorrow with Go 1.7.1?
teamwork!!! high five!!
I think we need to fix the CC=gcc issue.
We can use a gcc wrapper on the builder.
This happened. Go 1.7.1 includes s390x binaries on https://golang.org/dl/
Thanks, @jfrazelle, @broady, @mwhudson, @billotosyr ...
ππΌππΌ
On Wednesday, September 7, 2016, Brad Fitzpatrick notifications@github.com wrote:
Closed #16443 https://github.com/golang/go/issues/16443.
β You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/16443#event-781625003, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYNbK8X5YUq2BsDHkM8mUBhmOEfD6tgks5qnzhvgaJpZM4JQ2_8 .
Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3
Thanks!
Let's cross compile MIPS now!!!
On Wednesday, September 7, 2016, billotosyr notifications@github.com wrote:
Thanks!
β You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/16443#issuecomment-245445725, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYNbE-VoQK_pT7uBGuKtQqgg7suKGbtks5qn0KQgaJpZM4JQ2_8 .
Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3
This bug is about
1) how to cross-compile s390x release binaries for x/build/cmd/release 2) hosting said binaries on golang.org/dl (but only after we've figured out (1)
@jfrazelle had mentioned
CC=gcc-5-s390x-linux-gnu
. There a Debian package for that? We want to be able to build s390x binaries on linux-amd64. (All other release builds are built + tested on either native hardware or VMs, but we'll have to stop at justmake.bash
for s390x).As for (2), we briefly discussed having a section or column to denote which builds are at which support status. Let's defer that discussion until we have (1) figured out.
/cc @billotosyr, @adg, @broady