On Tue, May 26, 2015 at 9:17 AM, Lynn A. Boger <labo...@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 >> <andrewchambe...@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
