build: setting CC to "ccache clang" does not work

[tucnak]

I am not able to build Go from Git (tag: go1.5beta1) with bootstrapping go1.4.2 on OSX 10.10.4, cos of wrong handling of $CC environmental variable.

Steps to reproduce:

1. Get a custom CC, e.g. with ccache: export CC="ccache clang"
2. ./all.bash

Expected result: built Go with exit status 1
Observed result: https://gist.github.com/tucnak/77c6d21d299f3c73ee7e

Looks like build script cuts off everything after space char in $CC, so instead of calling ccache clang -E -dM ... it does ccache -E -dM ... which is wrong. There must be a regression!

[dominikh]

This affects building any package with cgo and isn't specific to building Go itself. It's a regression that was introduced in commit b38fa89

[ianlancetaylor]

The build doesn't discard the options after the space character--you can see them in your gist in GOGCCFLAGS. But you are correct that the build assumes that the first word in $CC is special, and that it doesn't need to keep the second work immediately after the first word as is true for something like "ccache clang".

I doubt this will be fixed for the 1.5 release. For now you will have to work around the problem, either by using a shell script or by omitting "ccache". Frankly, "ccache" isn't buying you anything here, so I recommend omitting it until this is fixed.

[dominikh]

For what it is worth, this was already semi-broken in Go 1.4, where it executes the following commands for CC="myccache gcc":

myccache gcc -E -dM -xc -m64 -I /tmp/go-build460939936/command-line-arguments/_obj/ -
myccache gcc -w -Wno-error -o/tmp/go-build460939936/command-line-arguments/_obj//_cgo_.o -gdwarf-2 -c -xc -I /tmp/go-build460939936/command-line-arguments/_obj/ -m64 -
myccache gcc -w -Wno-error -o/tmp/go-build460939936/command-line-arguments/_obj//_cgo_.o -gdwarf-2 -c -xc -I /tmp/go-build460939936/command-line-arguments/_obj/ -m64 -
myccache -I /tmp gcc -fPIC -m64 -pthread -fmessage-length=0 -print-libgcc-file-name

Where the last command isn't correct. So this is only partly a regression towards 1.4. It used to work, however, in 2012, where 7ae6872 specifically added support for it.

[ghost]

In my opinion, this isn't a golang bug.

cgo should just print a warning when CC contains spaces, so that the user can fix the actual cause of the problem.

Solution:

$ cat ~/bin/ccache-gcc 
#!/bin/bash
exec ccache /usr/bin/gcc "$@"

$ cat ~/bin/ccache-g++
#!/bin/bash
exec ccache /usr/bin/g++ "$@"

$ cat ~/.bashrc  (relevant lines only)
export PATH="${HOME}/bin:${PATH}"
export CC="ccache-gcc"
export CXX="ccache-g++"

[ianlancetaylor]

@atom-symbol I don't think I agree. I think you should be able to use spaces in $CC, and my understanding is that it used to work. It's not a major issue--as you say, you can always use a shell script--but I think we should fix it so that it works.

[ghost]

@ianlancetaylor CC="xxx yyy zzz" is ambiguous because it is uncertain whether the executable is "xxx" or "xxx yyy zzz". One way to decide is first to look whether there exists "xxx yyy zzz" executable, if it doesn't than for check existence of "xxx yyy", etc. go build does not know beforehand whether the name has spaces in it or not.

In the absolute, fixing this issue is impossible because solving it would require go build to know the mind's meaning of spaces in "xxx yyy zzz". Even if the build checks for the existence of "$PATH/xxx yyy zzz", it doesn't guarantee that the person really meant "$PATH/xxx yyy zzz" because the existence of "$PATH/xxx yyy zzz" may just be a coincidence that the person did not took into account.

[tucnak]

@atom-symbol CC="xxx yyy zzz" doesn't seem ambiguous to me, it's pretty clear for those familiar with unix. I also can't workaround CC with spaces, since it's a must-have for my build environment in Qt. IMHO, any sort of valid CC command should be interpreted by Go fine. And as @ianlancetaylor pointed out, it's been working inb4...

[ianlancetaylor]

@atom-symbol I agree with @tucnak. It's not ambiguous. Spaces separate arguments. That is historically how the CC environment variable works on Unix systems. Programs like make and autoconf support CC with spaces, and people expect to be able to use them.

[mdempsky]

There's a handful of problems.

First, in cmd/go when it sees a multifield CC value like "ccache clang", it resets CC="ccache" and moves "clang" into GOGCCFLAGS. (It also assumes it's able to insert arguments after the first field like "ccache -I objdir clang".)

Second, cmd/cgo doesn't use GOGCCFLAGS, so it doesn't see the "clang" argument.

Third, when you run "go env", it runs mkEnv again based on the updated environment, so the "clang" string disappears completely from the output of CC="ccache clang" go env, contrary to the environment actually provided to subtools.

Lastly, cmd/dist/test.go is currently written to assume $CC (and go env CC's output; it uses both for some reason) is a single field string, and it does use $GOGCCFLAGS.

[mdempsky]

This has never worked, and ccache isn't particularly useful for Go, so it doesn't seem like a blocker for Go 1.6. I'll look into it for Go 1.7.

[seankhliao]

resolved with #43808 and CL 284780
tracking with #43078