Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform

[William Hubbs]

All,

was this patch ever applied to gcc? If so, which versions?

Thanks,

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform

[William Hubbs]

On Tue, Nov 03, 2015 at 03:09:52PM +, James Le Cuirot wrote:
> On Tue, 3 Nov 2015 08:56:29 -0600
> William Hubbs  wrote:
> 
> > As has been pointed out in the thread so far, gcc-5 only supports
> > go-1.4. dev-lang/go is at 1.5, so really the only thing that should be
> > built with gccgo is dev-lang/go. Also, the golang eclasses are
> > designed to work with dev-lang/go, so they do not need a dependency
> > on gccgo.
> > 
> > I see gcc-5[go] as a separate Go compiler, but it will always be
> > behind dev-lang/go, so you will have things that build with
> > dev-lang/go but not gccgo. Also, the commands to do the builds are
> > completely different depending on which one you are using.
> 
> This is a lot like the situation with gcc's gcj and the icedtea Java
> JDK. The arguments are quite different so we have a wrapper script
> packaged as gcj-jdk. gcj only supports Java 6(ish?) and there are
> other compatibility issues though so we no longer support it as a
> general purpose JDK. Its only use is for bootstrapping icedtea. Now
> that Java has been open sourced and gcj has fallen so far behind, gcc
> are planning to scrap it so icedtea will need to find another way to
> bootstrap (probably JamVM) if it isn't to rely on prebuilt versions of
> itself.

I am definitely not against the patch to enable gccgo on all platforms.
This actually may make it possible for us to bootstrap dev-lang/go on
all of the platforms gccgo can be built on.

However, the situation with gcj sounds very similar to what is happening
with Go, and I want to take the same approach.

I do not recommend using gccgo as a general-purpose Go compiler. I may
be able to use it to bootstrap the general purpose compiler, which is
dev-lang/go, but That will probably be about it since it will always
be behind.

I am against virtual/go. If you want to enable gccgo go ahead, but
please do not create  virtual/go. Gccgo should only be used in special
cases, for example bootstrapping dev-lang/go.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform

[James Le Cuirot]

On Tue, 3 Nov 2015 08:56:29 -0600
William Hubbs  wrote:

> As has been pointed out in the thread so far, gcc-5 only supports
> go-1.4. dev-lang/go is at 1.5, so really the only thing that should be
> built with gccgo is dev-lang/go. Also, the golang eclasses are
> designed to work with dev-lang/go, so they do not need a dependency
> on gccgo.
> 
> I see gcc-5[go] as a separate Go compiler, but it will always be
> behind dev-lang/go, so you will have things that build with
> dev-lang/go but not gccgo. Also, the commands to do the builds are
> completely different depending on which one you are using.

This is a lot like the situation with gcc's gcj and the icedtea Java
JDK. The arguments are quite different so we have a wrapper script
packaged as gcj-jdk. gcj only supports Java 6(ish?) and there are
other compatibility issues though so we no longer support it as a
general purpose JDK. Its only use is for bootstrapping icedtea. Now
that Java has been open sourced and gcj has fallen so far behind, gcc
are planning to scrap it so icedtea will need to find another way to
bootstrap (probably JamVM) if it isn't to rely on prebuilt versions of
itself.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform

[Zac Medico]

On 11/02/2015 09:17 AM, Leno Hou wrote:
> -DEPEND=">=dev-lang/go-1.4:=
> +DEPEND="|| (
> + >=dev-lang/go-1.4:=
> + >=sys-devel/gcc-5.1.0:=[go]
> + )

Note that the council has recently decided that the := operator is
explicitly forbidden inside || ( ) constructs. The closest alternative
would be to use a USE flag as follows:

!gccgo? ( >=dev-lang/go-1.4:= ) gccgo? ( >=sys-devel/gcc-5.1.0:=[go] )
-- 
Thanks,
Zac

Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform

[Leno Hou]

On Tue, Nov 3, 2015 at 3:45 PM, Justin (jlec)  wrote:

> On 02/11/15 23:38, William Hubbs wrote:
> Hi William,
>
> but instead of adding
>
> DEPEND="||·(
> >=dev-lang/go-1.4
> >=sys-devel/gcc-5.1.0:=[go]
>
> to ebuilds, you could create a virtual/go with that dependency and make all
> packages depend on that instead of this || (). Maybe in future clang gets
> also
> support for go, then you would need to edit again all ebuilds. Having a
> virtual
> for that case is much simpler. This is how we are doing it for fortran.
>
> Another problem which you have with these split deps is the following.
> Imagine
> the user has gcc-5[go] installed, which fullfills the dependency
> requirement.
> But she selected gcc-4.9 as the active compiler, which doesn't have go
> support.
>
The build will fail. For fortran we test in pkg_setup if we have a working
> fortran compiler present. You would need to do the same for go compiler.
>
> Justin
>
>
Pretty good ! I'll take it.  thanks.

-Leno Hou

Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform

[William Hubbs]

On Tue, Nov 03, 2015 at 08:45:00AM +0100, Justin (jlec) wrote:
> On 02/11/15 23:38, William Hubbs wrote:
> > On Mon, Nov 02, 2015 at 09:12:30PM +0100, Justin Lecher (jlec) wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> How about a virtual here?
> > 
> > I don't see that working out to well because the compilers are
> > completely different from each other. As I said, the reference
> > implementation of the go language is dev-lang/go and the other one, that
> > is part of gcc, as I understand it, is not quite as fully developed as
> > dev-lang/go.
> > 
> > Thanks,
> > 
> > William
> > 
> 
> Hi William,
> 
> but instead of adding
> 
> DEPEND="||·(
>   >=dev-lang/go-1.4
>   >=sys-devel/gcc-5.1.0:=[go]
 
The || dependencies you list should not be needed in most cases.

As has been pointed out in the thread so far, gcc-5 only supports
go-1.4. dev-lang/go is at 1.5, so really the only thing that should be
built with gccgo is dev-lang/go. Also, the golang eclasses are designed
to work with dev-lang/go, so they do not need a dependency on gccgo.

Starting with go-1.5, most of the tools themselves are written in Go, so
you need an earlier version of Go installed to build it (this is where I
think I can use gccgo), but I'm not convinced yet about making it a
virtual.

> Another problem which you have with these split deps is the following. Imagine
> the user has gcc-5[go] installed, which fullfills the dependency requirement.
> But she selected gcc-4.9 as the active compiler, which doesn't have go 
> support.
> The build will fail. For fortran we test in pkg_setup if we have a working
> fortran compiler present. You would need to do the same for go compiler.

The issue I see is a user could have gcc-5[go] and go-1.6 installed in
the future. In that case, you would have packages that build with go-1.6
but not gcc-5[go], so gcc-5[go] would not fulfill the requirement.

I see gcc-5[go] as a separate Go compiler, but it will always be behind
dev-lang/go, so you will have things that build with dev-lang/go but not
gccgo. Also, the commands to do the builds are completely different
depending on which one you are using.

I'm not sure of a way to deal with those issues in a virtual like you propose.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform

[Justin (jlec)]

On 02/11/15 23:38, William Hubbs wrote:
> On Mon, Nov 02, 2015 at 09:12:30PM +0100, Justin Lecher (jlec) wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> How about a virtual here?
> 
> I don't see that working out to well because the compilers are
> completely different from each other. As I said, the reference
> implementation of the go language is dev-lang/go and the other one, that
> is part of gcc, as I understand it, is not quite as fully developed as
> dev-lang/go.
> 
> Thanks,
> 
> William
> 

Hi William,

but instead of adding

DEPEND="||·(
>=dev-lang/go-1.4
>=sys-devel/gcc-5.1.0:=[go]

to ebuilds, you could create a virtual/go with that dependency and make all
packages depend on that instead of this || (). Maybe in future clang gets also
support for go, then you would need to edit again all ebuilds. Having a virtual
for that case is much simpler. This is how we are doing it for fortran.

Another problem which you have with these split deps is the following. Imagine
the user has gcc-5[go] installed, which fullfills the dependency requirement.
But she selected gcc-4.9 as the active compiler, which doesn't have go support.
The build will fail. For fortran we test in pkg_setup if we have a working
fortran compiler present. You would need to do the same for go compiler.

Justin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform

[Justin Lecher (jlec)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

How about a virtual here?
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0

iQJ8BAEBCgBmBQJWN8OuXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmipKsQALPnDU6VwMdevmupO78LRk0d
F5Nu3U6bjEq/roAZYHBEAztFLLG+0fywvvObuhgEloCRpbfhf07QJUdX2LB/n2ep
iTGYkEfYYI565SkWF7CXnpE70g88KRPbFDYGgky1jfhmlQrJM5HpnZa0cy+cGGM/
peAnDjCha0pdvJtRWUGdonR+A1dsLso8z+hQmCVxmWqQkZT0rsxAzAVXlpg/3QFE
YevCio+ijwMwQV2wzD0gU4EtNKdaRXK1XKgI18UsOBwTYhGOlW5VWtjiixXZVGaC
L2QbZiNggCRlv4JuQsW8dEb3p29lQJmtRClMjq7AMjbD6Mzt2aVfbDqkhYLq3gS7
+bGepyX5dG3FVMFAnpfOyH/0+xAzV2L418/mGLJupfJfoF2yXNT76sGFKYsCrFgX
iA/dlBsfKhGNoYc4V7JH/ONuUHaMzgLq20opHeOkiPVB2Esv+2QWXQkppwVXQhBq
4w/Nge8HG7rEJ/dzg0ePLwQ6zCq7TafuwV8nTTE+gEfuitleQusQdkjEAHAYFRWH
W+L1t+W/W5jtAy6rPv93cWClAsuBTyEPHJpoaxa57cRUtwU1AxRvawKj2XwxrBAq
0h6PYd+qQh46kNS9tdGCEg8PXOdU2QedFPk+4iKrbccGJ6tnaUCt89oFfcBjHn27
NXQQXQoiLv8WA1n3twLg
=t7Bd
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform

[William Hubbs]

On Mon, Nov 02, 2015 at 12:17:26PM -0500, Leno Hou wrote:
> 1. go compiler only support x86 platform
> 2. gcc 5 includes go command to build go apps
> 3. for coreos enablement, it's use gcc 5 to build go apps

Also, once this is in place, I believe I could use gccgo to build go-1.5
and newer, which would get rid of the go-bootstrap package.

I think you will want to use dev-lang/go to build your packages, since
it is a newer compiler than the one in gccgo from what I understand.

Thanks,

William


signature.asc
Description: Digital signature

[gentoo-dev] [PATCH v1] enable gccgo for all platform

[Leno Hou]

1. go compiler only support x86 platform
2. gcc 5 includes go command to build go apps
3. for coreos enablement, it's use gcc 5 to build go apps

Signed-off-by: Leno Hou 
---
 app-admin/consul-template/consul-template-0.9.0-r1.ebuild   | 5 -
 app-admin/consul-template/consul-template-0.9.0.ebuild  | 5 -
 app-admin/consul-template/consul-template-.ebuild   | 5 -
 app-admin/consul/consul-0.5.2-r1.ebuild | 5 -
 app-admin/consul/consul-0.5.2.ebuild| 5 -
 app-admin/consul/consul-.ebuild | 5 -
 app-admin/fleet/fleet-0.11.0-r1.ebuild  | 5 -
 app-admin/fleet/fleet-0.11.1.ebuild | 5 -
 app-admin/fleet/fleet-0.11.5.ebuild | 5 -
 app-admin/fleet/fleet-.ebuild   | 5 -
 app-admin/logstash-forwarder/logstash-forwarder-0.4.0-r1.ebuild | 2 +-
 app-admin/mongo-tools/mongo-tools-3.0.5.ebuild  | 5 -
 app-admin/mongo-tools/mongo-tools-3.0.6.ebuild  | 5 -
 app-admin/mongo-tools/mongo-tools-3.0.7.ebuild  | 5 -
 app-crypt/etcd-ca/etcd-ca-0_p20140903.ebuild| 2 +-
 app-crypt/etcd-ca/etcd-ca-0_p20150423-r1.ebuild | 2 +-
 app-crypt/etcd-ca/etcd-ca-0_p20150423.ebuild| 2 +-
 app-emulation/docker/docker-1.6.1.ebuild| 5 -
 app-emulation/docker/docker-1.6.2.ebuild| 5 -
 app-emulation/docker/docker-1.7.1.ebuild| 6 +-
 app-emulation/flannel/flannel-0.5.4.ebuild  | 2 +-
 app-emulation/lxd/lxd-0.16.ebuild   | 5 -
 app-emulation/lxd/lxd-0.18.ebuild   | 5 -
 app-emulation/lxd/lxd-0.20.ebuild   | 5 -
 app-emulation/rkt/rkt-0.8.0.ebuild  | 5 -
 app-emulation/rkt/rkt-.ebuild   | 5 -
 app-emulation/runc/runc-0.0.2.ebuild| 2 +-
 dev-db/etcd/etcd-2.0.10-r1.ebuild   | 2 +-
 dev-db/etcd/etcd-2.2.1.ebuild   | 2 +-
 dev-db/etcdctl/etcdctl-0.4.6-r1.ebuild  | 2 +-
 dev-db/etcdctl/etcdctl-0.4.6.ebuild | 2 +-
 dev-db/go-etcd/go-etcd-0_p20141013-r1.ebuild| 2 +-
 dev-db/go-etcd/go-etcd-2.0.0-r1.ebuild  | 2 +-
 dev-db/go-etcd/go-etcd-2.0.0.ebuild | 2 +-
 dev-libs/go-fuse/go-fuse-0_p20140812-r1.ebuild  | 2 +-
 dev-libs/go-fuse/go-fuse-0_p20150422.ebuild | 2 +-
 dev-libs/go-fuse/go-fuse-.ebuild| 2 +-
 dev-libs/go-usb/go-usb-.ebuild  | 2 +-
 dev-vcs/hub/hub-2.2.0-r1.ebuild | 2 +-
 eclass/golang-base.eclass   | 2 +-
 sys-apps/lmctfy/lmctfy-0.5.0-r1.ebuild  | 5 -
 sys-apps/lmctfy/lmctfy-0.5.0.ebuild | 5 -
 sys-fs/etcd-fs/etcd-fs-0_p20140620.ebuild   | 5 -
 sys-fs/go-mtpfs/go-mtpfs-.ebuild| 5 -
 44 files changed, 120 insertions(+), 44 deletions(-)

diff --git a/app-admin/consul-template/consul-template-0.9.0-r1.ebuild 
b/app-admin/consul-template/consul-template-0.9.0-r1.ebuild
index cbc1059..a24ec80 100644
--- a/app-admin/consul-template/consul-template-0.9.0-r1.ebuild
+++ b/app-admin/consul-template/consul-template-0.9.0-r1.ebuild
@@ -14,7 +14,10 @@ LICENSE="MPL-2.0"
 SLOT="0"
 IUSE="test"
 
-DEPEND=">=dev-lang/go-1.4:=
+DEPEND="|| (
+   >=dev-lang/go-1.4:=
+   >=sys-devel/gcc-5.1.0:=[go]
+   )
test? ( dev-go/go-tools )
app-admin/consul
app-admin/vault"
diff --git a/app-admin/consul-template/consul-template-0.9.0.ebuild 
b/app-admin/consul-template/consul-template-0.9.0.ebuild
index 80a3de8..c35ed0a 100644
--- a/app-admin/consul-template/consul-template-0.9.0.ebuild
+++ b/app-admin/consul-template/consul-template-0.9.0.ebuild
@@ -14,7 +14,10 @@ LICENSE="MPL-2.0"
 SLOT="0"
 IUSE="test"
 
-DEPEND=">=dev-lang/go-1.4
+DEPEND="|| (
+   >=dev-lang/go-1.4
+   >=sys-devel/gcc-5.1.0:=[go]
+   )
test? ( dev-go/go-tools )
app-admin/consul
app-admin/vault"
diff --git a/app-admin/consul-template/consul-template-.ebuild 
b/app-admin/consul-template/consul-template-.ebuild
index 0dcf7f1..e43a1fd 100644
--- a/app-admin/consul-template/consul-template-.ebuild
+++ b/app-admin/consul-template/consul-template-.ebuild
@@ -15,7 +15,10 @@ LICENSE="MPL-2.0"
 SLOT="0"
 IUSE="test"
 
-DEPEND=">=dev-lang/go-1.4:=
+DEPEND="|| (
+

Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform

[William Hubbs]

On Mon, Nov 02, 2015 at 09:12:30PM +0100, Justin Lecher (jlec) wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> How about a virtual here?

I don't see that working out to well because the compilers are
completely different from each other. As I said, the reference
implementation of the go language is dev-lang/go and the other one, that
is part of gcc, as I understand it, is not quite as fully developed as
dev-lang/go.

Thanks,

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform

[Leno Hou]

On Tue, Nov 3, 2015 at 6:38 AM, William Hubbs  wrote:

> On Mon, Nov 02, 2015 at 09:12:30PM +0100, Justin Lecher (jlec) wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > How about a virtual here?
>
> I don't see that working out to well because the compilers are
> completely different from each other. As I said, the reference
> implementation of the go language is dev-lang/go and the other one, that
> is part of gcc, as I understand it, is not quite as fully developed as
> dev-lang/go.
>
>
As you said, I want to build packages use `go build` command.
1. The GCC 5 releases include a complete implementation of the Go 1.4 user
libraries. [1]
2. The Go 1.4 runtime is not fully merged, but that should not be visible
to Go programs.
3.  The GCC 5 includes go command like dev-lang/go
4.  Now I've successfully compiled docker on gentoo ppc64le by gcc5, see [2]
5.  So I think there're the same. but i'm not sure, Is dev/go-1.5  support
ppc64, s390 platform ?
 If not support,  DEPEND=" || ( >=dev-lang/go-1.4:=
>sys-devel/gcc-5.1.0:=[go] ) " would be better.

Links
[1] https://golang.org/doc/install/gccgo
[2] https://bpaste.net/show/e4c68cfec77c

-Leno Hou