Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 576290

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 packagesAssignee: 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
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.
Comment 1 William Hubbs gentoo-dev 2016-03-02 23:34:07 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.
Comment 2 William Hubbs gentoo-dev 2016-03-05 17:50:02 UTC
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.
Comment 3 Zac Medico gentoo-dev 2016-03-18 09:18:52 UTC
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.
Comment 4 Zac Medico gentoo-dev 2016-03-21 07:22:27 UTC
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).
Comment 5 Zac Medico gentoo-dev 2016-03-23 21:47:20 UTC
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.
Comment 6 Zac Medico gentoo-dev 2016-03-23 22:33:34 UTC
@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.
Comment 7 Aric Belsito 2016-03-24 01:55:03 UTC
@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.
Comment 8 Aric Belsito 2016-03-24 01:57:24 UTC
But I haven't tried to build it recently, and those functions appear to be available in musl's ucontext.h now.
Comment 9 Felix Janda 2016-03-24 08:08:53 UTC
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.
Comment 10 William Hubbs gentoo-dev 2016-04-14 16:15:12 UTC
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
Comment 11 Zac Medico gentoo-dev 2016-04-14 16:26:14 UTC
(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.
Comment 12 Aric Belsito 2016-04-14 21:28:14 UTC
> 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
Comment 13 Zac Medico gentoo-dev 2016-04-14 21:38:17 UTC
(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.
Comment 14 Andrius Štikonas 2016-04-19 14:46:09 UTC
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
Comment 15 Zac Medico gentoo-dev 2016-04-19 16:47:59 UTC
(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.
Comment 16 Felix Janda 2017-02-21 12:26:37 UTC
Bug 606970 is a new duplicate of this bug.

It would be nice to keep this bug open because it is not fixed.
Comment 17 Aric Belsito 2017-03-03 21:39:24 UTC
Agreed.

re: building gcc[go] with musl -- is anyone willing to create a standalone ucontext library?
Comment 18 Michael Seifert 2017-12-04 17:35:31 UTC
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 :)
Comment 19 Michael Seifert 2017-12-04 17:36:40 UTC
Sorry, wrong link… No idea how I got there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931
Comment 20 Haelwenn Monnier 2018-07-17 00:13:20 UTC
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
Comment 21 William Hubbs gentoo-dev 2020-01-22 20:21:12 UTC
This is fixed in 1.13.6.