Prior to =dev-lang/go-1.6-r2, I could build go on musl. As of that version, it now downloads prebuilt binary version of go instead of installing go-bootstrap. The prebuilt binary assumes that you are using glibc. Some solutions are that we could have versions of go built for bootstrapping on musl as well, or like dev-java/icedtea, dev-lang/go could build with whatever version of go was available to bootstrap it, for example: if dev-lang/go-bootstrap is installed, use it to bootstrap if dev-lang/go is installed, use it to bootstrap otherwise, download the prebuilt binaries. (would we even need this anymore?) This would be a matter of checking which package was installed and adjusting the GOROOT_BOOTSTRAP variable to the chosen bootstrapper, which could be: /usr/lib/go (dev-lang/go) /usr/lib/go1.4 (dev-lang/go-bootstrap) or ${WORKDIR}/go-${go_os}-${go_arch}-bootstrap which is what it is right now. This would fix the musl build issue, as well as the requirement of having to host all of the binaries for supported architectures.
We do need to have pre-built binaries, because we have new architectures added in Go 1.5 which are not supported in earlier versions of go, so I use go-1.4 to build go-1.5, then use that to build the bootstrap tarballs you see which are actually go-1.5 packaged only for use in bootstrapping. dev-lang/go-bootstrap isn't necessary any longer with this setup; I took that idea from the way other languages that need to bootstrap, such as haskell, are built. @blueness: Building the bootstrap tarballs for amd64/arm/x86 musl only needs to be done once, so how should I proceed? I can do it, but I would need user level access to a musl-based system, or, the other option is for me to give you the instructions for building them.
I spoke with @blueness, our muscl maintainer, and he advised me that this should not block stabilization. As I said above, if I can be given user level access to a musl system or if a chroot would work and someone can tell me how to set one up, I'll build the bootstrap tarballs for musl systems.
Created attachment 428486 [details, diff] go-1.6-r2.ebuild: support gccgo USE flag for alternative bootstrap With this patch, I've successfully bootstrapped go-1.6-r2 with sys-devel/gcc-5.3.0[go]. I needed a small toolchain.eclass patch which I will attach to bug 567806 shortly.
Created attachment 428694 [details, diff] go-1.6-r2.ebuild: support gccgo USE flag for alternative bootstrap Updated to prefer go-5 lookup via PATH variable (using type -P).
Created attachment 428876 [details, diff] go-1.6-r2.ebuild: support gccgo USE flag for alternative bootstrap Updated to use find | sort -V to locate go-5 from the highest available gcc version if go-5 is not found by the type -P lookup.
@williamh: I think the attached patch is good to apply, and close this bug. Then, it's just a matter of there being a working >=sys-devel/gcc-5[go] available for musl.
@zmedico According to voidlinux: https://github.com/voidlinux/void-packages/blob/master/srcpkgs/gcc/template#L133 According to alpine linux: http://git.alpinelinux.org/cgit/aports/tree/main/gcc/APKBUILD#n91 I don't believe we can build GO on musl.
But I haven't tried to build it recently, and those functions appear to be available in musl's ucontext.h now.
musl has *context functions in ucontext.h but they are not implemented. Applications trying to use them will get a linker error. @williamh: I think for bootstrapping a musl chroot will suffice. Links to stages are at https://wiki.gentoo.org/wiki/Project:Hardened_musl#Goals In view of bug 577098 it might be best to use a vanilla stage. As explained in bug 571700 it might also be necessary to patch gcc's stddef.h.
I was unable to build go 1.4.x in a musl chroot, so I was unable to create bootstrap binaries for musl. I did apply the patch from comment #5, and it is available in go1.6.1. Thanks for the report. William
(In reply to William Hubbs from comment #10) > I did apply the patch from comment #5, and it is available in go1.6.1. > > Thanks for the report. > > William Thanks! (In reply to Aric Belsito from comment #7) > @zmedico > > According to voidlinux: > https://github.com/voidlinux/void-packages/blob/master/srcpkgs/gcc/ > template#L133 > > According to alpine linux: > http://git.alpinelinux.org/cgit/aports/tree/main/gcc/APKBUILD#n91 > > I don't believe we can build GO on musl. I don't know about the current state. I think the first step is to build >=sys-devel-gcc-5[go], but that failed for me when I tried about a month ago with the experimental musl stages and musl overlay.
> I don't know about the current state. I think the first step is to build > >=sys-devel-gcc-5[go], but that failed for me when I tried about a month ago > with the experimental musl stages and musl overlay. Just looked inside sys-devel/gcc-5.3.0 libgo contains: makecontext in runtime/proc.c and runtime/go-callers.c setcontext in runtime/proc.c and runtime/go-signal.c getcontext in runtime/proc.c and runtime/go-signal.c The latest version of musl on git still does not contain any of the functions in ucontext.h outside of the header file, so GCC with go enabled will probably fail in the configure stage where it tests get,make,setcontext for usability. I think it's safe to say that this bug still isn't fixed.. Renaming because
(In reply to Aric Belsito from comment #12) > I think it's safe to say that this bug still isn't fixed.. Renaming because Since the boostrap tarball approach seems much less sustainable than the sys-devel/gcc[go] approach, I think you need to focus on gcc first (that should be a separate bug report for the musl overlay with respect to gcc, I guess). Once you have a working sys-devel/gcc[go], then hopefully dev-lang/go[gccgo] will just work, but we won't know until you have a working sys-devel/gcc[go] for musl.
Unfortunately gccgo bootstrap fails here. /usr/bin/go-5 does not work when it is symlinked (which ebuild does now) and fails with error: gcc-config: error: could not run/locate 'go' I've opened a new bug 579958
(In reply to Andrius Štikonas from comment #14) > Unfortunately gccgo bootstrap fails here. /usr/bin/go-5 does not work when > it is symlinked (which ebuild does now) and fails with error: > > gcc-config: error: could not run/locate 'go' > > I've opened a new bug 579958 Fixed now. Apparently I never tested that particular case, since I was afraid to set gcc-5 as my default compiler.
Bug 606970 is a new duplicate of this bug. It would be nice to keep this bug open because it is not fixed.
Agreed. re: building gcc[go] with musl -- is anyone willing to create a standalone ucontext library?
Here is the upstream bug for further reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70787 Doesn't seem to be top priority, though :)
Sorry, wrong link… No idea how I got there. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931
Just wanted to say that I went with the dev-lang/go-bootstrap alias go1.4 route with success for getting go on musl. Here is the commits I made on my overlay for it: https://gitlab.com/lanodan/overlay/compare/3d86933...1227f45
This is fixed in 1.13.6.