cmd/go: allow ccache to work by using relative paths when invoking the C compiler #12930
Labels
Milestone
Comments
ghost
added this to the 
|
Those absolute paths are in temporary directories, the names of which change from run to run. We run the actual build in the package directory. I mean, I guess we could say ../../../../../../../$WORK/_/home/.../misc/cgo/life/_obj/cgo_main.c instead of $WORK//home/.../misc/cgo/life/_obj/_cgo_main.c, but does that really make sense? If ccache works with the ../../../../ but not without, that seems like a bug in ccache. |
|
Still confused about how this could possibly work, since $WORK is different every time the go command runs. I think this is probably not the go command's fault. Given the lack of reply, closing. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Executing
"CC=ccache-gcc go build"multiple times in misc/cgo/life always causes ccache to miss. This is because the build is passing absolute paths to the C compiler.Current output of
"CC=ccache-gcc go build -x":ccache-gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -I $WORK/_/home/.../misc/cgo/life/_obj/ -g -O2 -o $WORK/_/home/.../misc/cgo/life/_obj/_cgo_main.o -c $WORK/_/home/.../misc/cgo/life/_obj/_cgo_main.cExpected output of
"CC=ccache-gcc go build -x":ccache-gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -I . -g -O2 -o _cgo_main.o -c _cgo_main.cThe text was updated successfully, but these errors were encountered: