>Number:         3873
>Category:       bin
>Synopsis:       mkdep passes wrong args to wrong cc
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 16 07:35:01 1997
>Last-Modified:
>Originator:     der Mouse
>Organization:
	Dis-
>Release:        -current sup of July 8 AM (also as of now)
>Environment:
	Any (noticed on SPARC IPC)
>Description:
	mkdep runs produce output like

	cc: /usr/ucb: No such file or directory
	cc: /usr/etc: No such file or directory

	for each nonexistent directory in $PATH, and pay no attention
	to .c files named on the command line.  Running mkdep with an
	explicit sh -x from the command line reveals that this is
	because it's running cc -M with the directories in $PATH as
	arguments, rather than the script's arguments.  It also is
	using the _last_ cc found on the path, rather than the _first_
	(this can also be seen by using sh -x).  The generated .depend
	file is empty, which is hardly surprising since cc -M never got
	any .c files to process.

	Both symptoms disappear if $CC is set.
>How-To-Repeat:
	Add a nonexistent directory or two to your $PATH, make sure $CC
	is not set, then run mkdep.  Or, run "sh -x /usr/bin/mkdep ..."
	(without $CC set) and inspect the output.
>Fix:
	I suspect the "set $PATH" in the search for cc/gcc is
	destroying the argument list passed to cc with "$@".  All I can
	think of as a fix is to run the search for cc/gcc in a
	subshell, using backquotes to capture the result.

	I am currently attempting a C version of mkdep, which will
	allow fixing all these problems, and some possible other ones
	(such as path elements containing shell metacharacters breaking
	the $pathel/name construction in the search for cc/gcc).

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>Audit-Trail:
>Unformatted: