Summary: | dev-lang/go no longer builds on musl (no bootstrap tarball is available, and sys-devel/gcc[go] does not build) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Aric Belsito <lluixhi> |
Component: | Current packages | Assignee: | William Hubbs <williamh> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | blueness, gentoobugs, m.seifert, tsmksubc, zmedico |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
go-1.6-r2.ebuild: support gccgo USE flag for alternative bootstrap
go-1.6-r2.ebuild: support gccgo USE flag for alternative bootstrap go-1.6-r2.ebuild: support gccgo USE flag for alternative bootstrap |
Description
Aric Belsito
2016-03-02 20:56:08 UTC
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. |