All, please add your keywords to dev-lang/go-1.6-r2. This version uses provided bootstrap tarballs, so let me know if one is missing. Thanks, William
Hi, maybe I'm placing this on the wrong place, but I think these changes interferes on Gentoo systems that do not use glibc (musl, for example). In that cases, I think that go-bootstrap-1.4.3 should be used (with patches like Alpine Linux uses), but I haven't tested this yet. Regards and apologies again.
(In reply to Joel from comment #1) > Hi, maybe I'm placing this on the wrong place, but I think these changes > interferes on Gentoo systems that do not use glibc (musl, for example). Please test there and let me know by filing separate bugs for any issues. > In that cases, I think that go-bootstrap-1.4.3 should be used (with patches > like Alpine Linux uses), but I haven't tested this yet. go-bootstrap-1.4.3 really can't be used because Gentoo supports many more architectures than Alpine, and some of these only work for go-1.5 and go-1.6. This article talks about the process we have to use to bootstrap Go. [1] http://dave.cheney.net/2015/10/16/bootstrapping-go-1-5-on-non-intel-platforms > Regards and apologies again.
(In reply to Joel from comment #1) > Hi, maybe I'm placing this on the wrong place, but I think these changes > interferes on Gentoo systems that do not use glibc (musl, for example). > > In that cases, I think that go-bootstrap-1.4.3 should be used (with patches > like Alpine Linux uses), but I haven't tested this yet. > > Regards and apologies again. open a new bug and outline the bug in detail, how to reproduce the issue. have the bug block on musl-porting
Hi William, what script/procedure did you use to build the bootstrap tarballs? I have go-1.5.3 (via go-bootstrap-1.4.3) installed on Solaris amd64 and would like to have a tarball for that.
commit d451ba83eeb192a324bb6d6910e37aac234005d8 (HEAD -> master) Merge: 2ae041e de47eab Author: Patrice Clement <monsieurp@gentoo.org> Date: Sat Feb 27 20:23:39 2016 +0000 Merge github#922: dev-lang/go: add ~amd64-fbsd, ~x86-fbsd keyword. Keyword dev-lang/go for FreeBSD x86/amd64. Pull-Request: https://github.com/gentoo/gentoo/pull/922 Gentoo-Bug: https://bugs.gentoo.org/575510 Reporter: Yuta Satoh <nigoro.dev@gmail.com> Signed-off-by: Patrice Clement <monsieurp@gentoo.org>
(In reply to Fabian Groffen from comment #4) > Hi William, what script/procedure did you use to build the bootstrap > tarballs? I have go-1.5.3 (via go-bootstrap-1.4.3) installed on Solaris > amd64 and would like to have a tarball for that. Hi Fabian, the procedure is discussed in the blog post I cited above in comment #4, and the use of the bootstrap.bash script is discussed on the installing from source page [1]. Since it is a 5-10 minute process and any go can cross-compile a bootstrap toolchain for any target, I went ahead and built a bootstrap tarball for amd64 Solaris. Please test with that one and let me know if it doesn't work. FYI, The procedure is that you build go 1.4.x then bootstrap go 1.5.x from that. Then, in the go1.5.x installation, you do this: cd go1.5/src env GOROOT=/path/to/go1.5 GOARCH=<targetarch> GOOS=<targetos> ./bootstrap.bash That creates the bootstrapped tarball for the specified GOARCH and GOOS. These bootstrap tarballs should not have to be changed, because the idea is just to have a version of Go available to build the newest version. [1] https://golang.org/doc/install/source
Hi William, Thanks, now I understand, you just cross-compile it (more or less). I am testing the solaris one you created now. I will likely attempt x86-solaris and x86-macos as well. I've lowercased Kernel_SunOS, because of Error(s) in metadata for 'dev-lang/go-1.6-r2': SRC_URI: USE flag 'Kernel_SunOS' referenced in conditional 'Kernel_SunOS?' is not in IUSE Unfortunately, the bootstrap tarball seems to be different: ##### Building Go bootstrap tool. cmd/dist ERROR: Cannot find /gentoo/prefix64/var/tmp/portage/dev-lang/go-1.6-r2/work/go-solaris-amd64-bootstrap/bin/go. Set $GOROOT_BOOTSTRAP to a working Go tree >= Go 1.4. investigating
problem found, amd64 keyword isn't used, x64-solaris is :)
(In reply to Fabian Groffen from comment #7) > Hi William, > > Thanks, now I understand, you just cross-compile it (more or less). I am > testing the solaris one you created now. I will likely attempt x86-solaris > and x86-macos as well. I've lowercased Kernel_SunOS, because of Hi Fabian, I would like all bootstrap tarballs stored in ${BOOTSTRAP_DIST}, so I'll take a look at building those this afternoon. I thought I read somewhere that x86-macos was no longer supported upstream, but I may be wrong. Give me an hour or so and I'll be able to build x86-solaris for you for sure then also x86-macos if it is supported.
(In reply to William Hubbs from comment #9) > (In reply to Fabian Groffen from comment #7) > > Hi William, > > > > Thanks, now I understand, you just cross-compile it (more or less). I am > > testing the solaris one you created now. I will likely attempt x86-solaris > > and x86-macos as well. I've lowercased Kernel_SunOS, because of Hi Fabian, I was unable to build an x86-solaris bootstrap tarball. After researching, it looks like x86-solaris isn't supported upstream. See the goos/goarch combinations table [1]. It looks like I can build an x86-macos bootstrap tarball. However, I am confused about 32-bit Darwin's status upstream. It looks like they aren't interested in it [2]. What do you think? do you want me to go ahead and upload the Darwin-386-bootstrap tarball I have? Thanks, William [1] https://golang.org/doc/install/source [2] https://github.com/golang/go/issues/13425
32-bits Intel Darwin is indeed less relevant nowadays, I'm ok with leaving it as is until we get a request for it. Thanks for your efforts!
Why do we do this?
arm64 and prefix are complete, we still need arm, ppc64 and x86. Thanks, William
Tests all passed on ppc64. A lot of "Unable to trace static ELF" messages but I guess that's expected.
Added ~arm keyword, thanks to steev@gentoo.org for testing.
@x86: What is your status? Can we get this keyworded soon? Thanks much, William
I added the ~x86 keyword after clearing this with @ago. Thanks, William
