Subject: bin/3138: [dM] mkdep(1) always uses /usr/bin/gcc
To: None <gnats-bugs@gnats.netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: netbsd-bugs
Date: 01/24/1997 20:23:12
>Number:         3138
>Category:       bin
>Synopsis:       [dM] mkdep(1) always uses /usr/bin/gcc
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 24 17:35:01 1997
>Last-Modified:
>Originator:     der Mouse
>Organization:
	Dis-
>Release:        1.2_BETA
>Environment:
	System: NetBSD Twig.Rodents.Montreal.QC.CA 1.2_BETA NetBSD 1.2_BETA (TWIG) #0: Tue Sep 3 00:45:26 EDT 1996 mouse@Twig.Rodents.Montreal.QC.CA:/mouse/sources/working-usr-src/sys/arch/sun3/compile/TWIG sun3

>Description:
	mkdep(1) always uses /usr/bin/gcc (or more precisely, whatever
	"gcc" maps to according to PATH=/bin:/usr/bin:/usr/ucb), even
	when the normal path search mechanisms would locate a different
	binary.  This means that compiling with cc won't necessarily
	use the include files mkdep finds; in some cases, mkdep can
	produce errors when cc won't.  (In my case, the cc binary
	that's first in my path is a wrapper program that runs
	/usr/bin/cc with assorted additional arguments, in particular,
	certain -I options.)  The manpage for mkdep is silent on
	exactly what it uses as "the C compiler"; if it's supposed to
	always use /usr/bin/gcc directly, this is really a doc-bug (and
	incidentally mkdep becomes much less useful than I had assumed
	it would be - I simply will be unable to use it).
>How-To-Repeat:
	% mkdir ~/tmp
	% set path = ( ~/tmp $path )
	% cat > ~/tmp/cc
	#! /bin/sh
	exec /usr/bin/cc -I$(HOME)/tmp "$@"
	<EOF>
	% chmod 755 ~/tmp/cc
	% touch ~/tmp/something.h
	% cat > foo.c
	#include <something.h>
	void do_nothing(void) { }
	<EOF>
	% cc -c foo.c
	% mkdep foo.c

	Note the complaint from mkdep, contrast it with the lack of
	complaint from cc.
>Fix:
	I would be inclined to remove the PATH setting from mkdep; it
	is not privileged, so there's no reason I can see why it
	shouldn't use its callers' PATH.  (I'd probably also make it
	use "cc" instead of "gcc", but that's a separate issue.)

					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: