GO tools for gccgo cross

GO tools for gccgo cross

[Lynn A. Boger]

Hi,

I've been experimenting with the go tools and how to make them work for 
cross gccgo builds.

In golang I think there is just one 'go' tool and the cross build 
targets are specified by the setting of GOARCH and GOOS.  So why 
couldn't the same be done with gccgo?

That means, on any given system, I think we just need to build the 
native gccgo and the go tools that are built with it.  No need to build 
different go tools for each cross target.  If a cross build is needed, 
then set the GOARCH and GOOS values appropriately and invoke the native 
go (for gccgo) tool.  Source changes are needed for the go tool source 
to determine the correct cross compiler name based on the GOARCH and 
GOOS settings, and then use that cross compiler where needed for 
building or linking instead of always using "gccgo".  I was able to make 
these changes and get this to work -- I built gccgo programs targeted 
for ppc64le on an x86_64.

Re: [gofrontend-dev] GO tools for gccgo cross

[Ian Lance Taylor]

On Tue, Feb 3, 2015 at 11:52 AM, Lynn A. Boger
<laboger@linux.vnet.ibm.com> wrote:
>
> I've been experimenting with the go tools and how to make them work for
> cross gccgo builds.
>
> In golang I think there is just one 'go' tool and the cross build targets
> are specified by the setting of GOARCH and GOOS.  So why couldn't the same
> be done with gccgo?
>
> That means, on any given system, I think we just need to build the native
> gccgo and the go tools that are built with it.  No need to build different
> go tools for each cross target.  If a cross build is needed, then set the
> GOARCH and GOOS values appropriately and invoke the native go (for gccgo)
> tool.  Source changes are needed for the go tool source to determine the
> correct cross compiler name based on the GOARCH and GOOS settings, and then
> use that cross compiler where needed for building or linking instead of
> always using "gccgo".  I was able to make these changes and get this to work
> -- I built gccgo programs targeted for ppc64le on an x86_64.

I agree that setting GOARCH and GOOS should change the default name of
the gccgo compiler that the go tool uses.

Ian

Re: [gofrontend-dev] GO tools for gccgo cross

[Ian Lance Taylor]

On Tue, Mar 17, 2015 at 7:36 AM,  <laboger@linux.vnet.ibm.com> wrote:
> I have a patch to get gccgo to work on cross.
>
> Is it too late to try and get this into gcc 5.0?

I think it's still possible.  Depends on how small and safe it is.

Ian


> On Tuesday, February 3, 2015 at 2:18:39 PM UTC-6, Ian Lance Taylor wrote:
>>
>> On Tue, Feb 3, 2015 at 11:52 AM, Lynn A. Boger
>> <lab...@linux.vnet.ibm.com> wrote:
>> >
>> > I've been experimenting with the go tools and how to make them work for
>> > cross gccgo builds.
>> >
>> > In golang I think there is just one 'go' tool and the cross build
>> > targets
>> > are specified by the setting of GOARCH and GOOS.  So why couldn't the
>> > same
>> > be done with gccgo?
>> >
>> > That means, on any given system, I think we just need to build the
>> > native
>> > gccgo and the go tools that are built with it.  No need to build
>> > different
>> > go tools for each cross target.  If a cross build is needed, then set
>> > the
>> > GOARCH and GOOS values appropriately and invoke the native go (for
>> > gccgo)
>> > tool.  Source changes are needed for the go tool source to determine the
>> > correct cross compiler name based on the GOARCH and GOOS settings, and
>> > then
>> > use that cross compiler where needed for building or linking instead of
>> > always using "gccgo".  I was able to make these changes and get this to
>> > work
>> > -- I built gccgo programs targeted for ppc64le on an x86_64.
>>
>> I agree that setting GOARCH and GOOS should change the default name of
>> the gccgo compiler that the go tool uses.
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "gofrontend-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gofrontend-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [gofrontend-dev] GO tools for gccgo cross

[Lynn A. Boger]

I got sidetracked with some bug fixes and decided the change for this 
was not real small.

Should this be submitted to gofrontend, or to the golang master source?

On 03/17/2015 01:27 PM, Ian Lance Taylor wrote:
> On Tue, Mar 17, 2015 at 7:36 AM,  <laboger@linux.vnet.ibm.com> wrote:
>> I have a patch to get gccgo to work on cross.
>>
>> Is it too late to try and get this into gcc 5.0?
> I think it's still possible.  Depends on how small and safe it is.
>
> Ian
>
>
>> On Tuesday, February 3, 2015 at 2:18:39 PM UTC-6, Ian Lance Taylor wrote:
>>> On Tue, Feb 3, 2015 at 11:52 AM, Lynn A. Boger
>>> <lab...@linux.vnet.ibm.com> wrote:
>>>> I've been experimenting with the go tools and how to make them work for
>>>> cross gccgo builds.
>>>>
>>>> In golang I think there is just one 'go' tool and the cross build
>>>> targets
>>>> are specified by the setting of GOARCH and GOOS.  So why couldn't the
>>>> same
>>>> be done with gccgo?
>>>>
>>>> That means, on any given system, I think we just need to build the
>>>> native
>>>> gccgo and the go tools that are built with it.  No need to build
>>>> different
>>>> go tools for each cross target.  If a cross build is needed, then set
>>>> the
>>>> GOARCH and GOOS values appropriately and invoke the native go (for
>>>> gccgo)
>>>> tool.  Source changes are needed for the go tool source to determine the
>>>> correct cross compiler name based on the GOARCH and GOOS settings, and
>>>> then
>>>> use that cross compiler where needed for building or linking instead of
>>>> always using "gccgo".  I was able to make these changes and get this to
>>>> work
>>>> -- I built gccgo programs targeted for ppc64le on an x86_64.
>>> I agree that setting GOARCH and GOOS should change the default name of
>>> the gccgo compiler that the go tool uses.
>>>
>>> Ian
>> --
>> You received this message because you are subscribed to the Google Groups
>> "gofrontend-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to gofrontend-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>

Re: [gofrontend-dev] GO tools for gccgo cross

[Ian Lance Taylor]

On Tue, Apr 14, 2015 at 6:14 AM, Lynn A. Boger
<laboger@linux.vnet.ibm.com> wrote:
> I got sidetracked with some bug fixes and decided the change for this was
> not real small.
>
> Should this be submitted to gofrontend, or to the golang master source?

Let's try it in the master repo.  Thanks.

Ian


> On 03/17/2015 01:27 PM, Ian Lance Taylor wrote:
>>
>> On Tue, Mar 17, 2015 at 7:36 AM,  <laboger@linux.vnet.ibm.com> wrote:
>>>
>>> I have a patch to get gccgo to work on cross.
>>>
>>> Is it too late to try and get this into gcc 5.0?
>>
>> I think it's still possible.  Depends on how small and safe it is.
>>
>> Ian
>>
>>
>>> On Tuesday, February 3, 2015 at 2:18:39 PM UTC-6, Ian Lance Taylor wrote:
>>>>
>>>> On Tue, Feb 3, 2015 at 11:52 AM, Lynn A. Boger
>>>> <lab...@linux.vnet.ibm.com> wrote:
>>>>>
>>>>> I've been experimenting with the go tools and how to make them work for
>>>>> cross gccgo builds.
>>>>>
>>>>> In golang I think there is just one 'go' tool and the cross build
>>>>> targets
>>>>> are specified by the setting of GOARCH and GOOS.  So why couldn't the
>>>>> same
>>>>> be done with gccgo?
>>>>>
>>>>> That means, on any given system, I think we just need to build the
>>>>> native
>>>>> gccgo and the go tools that are built with it.  No need to build
>>>>> different
>>>>> go tools for each cross target.  If a cross build is needed, then set
>>>>> the
>>>>> GOARCH and GOOS values appropriately and invoke the native go (for
>>>>> gccgo)
>>>>> tool.  Source changes are needed for the go tool source to determine
>>>>> the
>>>>> correct cross compiler name based on the GOARCH and GOOS settings, and
>>>>> then
>>>>> use that cross compiler where needed for building or linking instead of
>>>>> always using "gccgo".  I was able to make these changes and get this to
>>>>> work
>>>>> -- I built gccgo programs targeted for ppc64le on an x86_64.
>>>>
>>>> I agree that setting GOARCH and GOOS should change the default name of
>>>> the gccgo compiler that the go tool uses.
>>>>
>>>> Ian
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "gofrontend-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to gofrontend-dev+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>

Re: [gofrontend-dev] Re: GO tools for gccgo cross

[Ian Lance Taylor]

On Fri, May 22, 2015 at 2:01 PM, Andrew Chambers
<andrewchamberss@gmail.com> wrote:
>>
>> For example, I've tested on an x86, built cross compilers for ppc64 and
>> ppc64le and then can invoke the native go tool (built to run on x86) to
>> compile with either target compiler by changing my GOARCH value.  I don't
>> want to have a separate cross go tool to use only for ppc64 and another to
>> use only for ppc64le.
>
>
> If I have mips-linux-gcc , mips-linux-gccgo, there is no reason  to not have
> a mips-linux-go which automatically uses the correct gccgo and is installed
> into the same prefix.
> It is in line with how gcc works currently, Also, for a canadian cross
> compile (--build differs to --host), building a new go tool is necessary
> anyway.

With the gc toolchain, it's very convenient to be able to say
GOARCH=arm go build program to get the ARM version of a program.  I
don't think we should move away from that in order to follow GCC
conventions.  The Go conventions are better and easier to use.

Ian

Re: [gofrontend-dev] Re: GO tools for gccgo cross

[Ian Lance Taylor]

On Fri, May 22, 2015 at 3:11 PM, Andrew Chambers
<andrewchamberss@gmail.com> wrote:
>
> I'm not suggesting breaking go conventions, I just think the default if no
> GOARCH is specified then it should match --target.

Sounds good to me.

> Perhaps we could check the symlink name for the target triple if no GOARCH
> is set.

We should probably build it into the tool, perhaps in zdefaultcc.go
created in gotools/Makefile.am.

Ian

Re: [gofrontend-dev] Re: GO tools for gccgo cross

[Lynn A. Boger]

On 05/22/2015 05:50 PM, Ian Lance Taylor wrote:
> On Fri, May 22, 2015 at 3:11 PM, Andrew Chambers
> <andrewchamberss@gmail.com> wrote:
>> I'm not suggesting breaking go conventions, I just think the default if no
>> GOARCH is specified then it should match --target.
> Sounds good to me.
>
>> Perhaps we could check the symlink name for the target triple if no GOARCH
>> is set.
> We should probably build it into the tool, perhaps in zdefaultcc.go
> created in gotools/Makefile.am.
I'm not sure exactly what is meant here.

If you build a native gccgo and its corresponding native go tool, I 
think it should have the plain name 'go' and accept any GOARCH and GOOS 
values to indicate the cross compile target, and use the correct cross 
gccgo (via target triple name) based on that.  golang determines the 
cross compiler based on the GOOS and GOARCH settings and I think it 
should work the same way when using gccgo if possible.

If you build a cross gccgo and want to have a cross go tool dedicated to 
that cross gccgo then the cross go tool it makes sense to have the 
target triple name so it is clear it is not the native go tool.  
(Realize in this case the native gccgo will have to have been built 
since any go tool, cross or not, has to run natively and have been built 
using the native gccgo.)

What symlink do you mean?  On one system (like a build machine) there 
could be multiple cross gccgo compilers and therefore multiple cross go 
tools for those compilers, so then what is the symlink and what would it 
be set to?

> Ian
>
>

Re: [gofrontend-dev] Re: GO tools for gccgo cross

[Ian Lance Taylor]

On Tue, May 26, 2015 at 9:17 AM, Lynn A. Boger
<laboger@linux.vnet.ibm.com> wrote:
>
> On 05/22/2015 05:50 PM, Ian Lance Taylor wrote:
>>
>> On Fri, May 22, 2015 at 3:11 PM, Andrew Chambers
>> <andrewchamberss@gmail.com> wrote:
>>>
>>> I'm not suggesting breaking go conventions, I just think the default if
>>> no
>>> GOARCH is specified then it should match --target.
>>
>> Sounds good to me.
>>
>>> Perhaps we could check the symlink name for the target triple if no
>>> GOARCH
>>> is set.
>>
>> We should probably build it into the tool, perhaps in zdefaultcc.go
>> created in gotools/Makefile.am.
>
> I'm not sure exactly what is meant here.
>
> If you build a native gccgo and its corresponding native go tool, I think it
> should have the plain name 'go' and accept any GOARCH and GOOS values to
> indicate the cross compile target, and use the correct cross gccgo (via
> target triple name) based on that.  golang determines the cross compiler
> based on the GOOS and GOARCH settings and I think it should work the same
> way when using gccgo if possible.

I agree.


> If you build a cross gccgo and want to have a cross go tool dedicated to
> that cross gccgo then the cross go tool it makes sense to have the target
> triple name so it is clear it is not the native go tool.  (Realize in this
> case the native gccgo will have to have been built since any go tool, cross
> or not, has to run natively and have been built using the native gccgo.)

My main concern is that there is no GCC build procedure that will
build such a tool.


> What symlink do you mean?  On one system (like a build machine) there could
> be multiple cross gccgo compilers and therefore multiple cross go tools for
> those compilers, so then what is the symlink and what would it be set to?

I was interpreting this as suggesting that the program could look at
argv[0] to see if it has been installed as TARGET-go.  I don't think
that is a good idea.  But perhaps Andrew meant something different.

Ian