Hello Eric, Ian, * Ian Lance Taylor wrote on Tue, Oct 12, 2010 at 11:06:07PM CEST: > Ralf Wildenhues writes: > > >> +...@defmac AC_PROG_GO (@ovar{compiler-search-list}) > >> +Find the Go compiler to use. Check whether the environment variable > >> +...@code{gccgo} is set; if so, then set output variable @code{GCCGO} to > >> its > >> +value. > > > > Why name the variable GCCGO? In line with other compiler variables > > would be something like GOC (for GO Compiler) or GOCC, that would also > > match with GOFLAGS. Do you expect this interface to never apply to > > non-GCC implementations of Go? > > There is another Go compiler, which is called either 6g or 8g depending > on the target, but it works differently. It does not use a -c option to > compile, but instead uses a different program (6l or 8l) to link. Also > these tools generate .6 or .8 files rather than .o files, and the linker > gets the libraries directly from the .6/.8 files rather than from the > command line. So I wasn't sure whether it made sense to use the smae > make variable for both. > > That said, I'm not wedded to GCCGO, and if y'all think it would be > better to use GOC or GOCC, I'm fine with making the change. It's true > that it would be possible to write a driver program for 6g/8g which make > them act more like gccgo, though the reverse would be harder.
Eric, do you have any input on this open question? Have you had a chance to look at the patch? It otherwise seems low-danger to me, but I wouldn't want to move forward on the Libtool sister patch without this one cleared. > > Just for reference, can you post the output of > > make check TESTSUITEFLAGS='-k go -v -x' > > > > with a Go compiler in $PATH? > > Attached. That looks fine to me. Thanks, Ralf