code review 206077: Invoke an ANSI C pre-processor as "cpp", not "/bin/cpp"

Invoke an ANSI C pre-processor as "cpp", not "/bin/cpp"

The compilers' -p option currently assumes that /bin/cpp
exists.  This is not the case on all platforms including
OS X.

As the compilers invoke cpp via lib9/exec.c:exec() which
is implemented with execvp, just specify "cpp" and not
"/bin/cpp" to find cpp anywhere in the user's search path.

[giles, 2010-02-12 00:55:17]

Hello golang-dev@googlegroups.com,

I'd like you to review this change.

[rsc, 2010-02-12 14:45:10]

It should probably be /usr/bin/cpp which is the
standard location on Unix (the /bin/cpp is from Plan 9)
but note that it's probably a mistake to be using it
in the first place.  For linking in arbitrary C code
the suggested approach is to use cgo with gcc.

Russ

[giles, 2010-02-12 21:51:09]

Russ Cox <rsc@golang.org> wrote:

> It should probably be /usr/bin/cpp which is the
> standard location on Unix (the /bin/cpp is from Plan 9)
> ...

Either way would be an improvement; I'm not fussy, although
I'm wary of "standard location"; doesn't/didn't Solaris use
/usr/ccs/bin for some of the development tools?

Bottom line is /bin/cpp doesn't work on all existing ports,
and something -- any something -- that did work would be
better. :-)

> but note that it's probably a mistake to be using it
> in the first place.  For linking in arbitrary C code
> the suggested approach is to use cgo with gcc.

Yes; I merely noticed this in passing while trying
unsuccessfully to find a workaround for "invalid recursive
type" compiler errors hit while using cgo, which I think are
due to this problem:

http://groups.google.com/group/golang-dev/browse_thread/thread/b70e96c96629197d

Cheers,

Giles

[rsc, 2010-02-16 19:22:03]

LGTM

[rsc, 2010-02-16 19:32:42]

*** Submitted as http://code.google.com/p/go/source/detail?r=0f83c99edea0 ***

cc: use "cpp" anywhere in path, not "/bin/cpp"

R=rsc
CC=golang-dev
http://codereview.appspot.com/206077

Committer: Russ Cox <rsc@golang.org>