>Number:         10162
>Category:       bin
>Synopsis:       gcc linking  via collect2 fails when ld not in $PATH
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat May 20 15:06:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        netbsd-current as at approximately 2000-04-30
>Organization:
	
>Environment:
	
System: NetBSD Cup.DSG.Stanford.EDU 1.4.1 NetBSD 1.4.1 (GENERIC) #0: Tue Nov 9 12:18:04 PST 1999 jonathan@Cup.DSG.Stanford.EDU:/src/NetBSD/src/sys-1.4-release/src/sys/arch/i386/compile/GENERIC i386

I acutally verified this on i386 -current snapshots from ca. April 30.

>Description:


>How-To-Repeat:
	do a from-scratch install of a 2000050x i386 snapshot.
	install base and comp. install the tcsh package.
        (the one I used dates back to 1.4S).
	create a new user account by hand, using csh or tcsh as shell,
	and log in as that user.
	Note that  PATH is not set, but {t,}csh defailts its $path to
	include /bin and /usr/bin.

	invoke cc on a hello-world program.
	Observe that cc invokes cpp,  cc1, and collect2  successfully,
	but when collect2 attempts to exec ld, it fails.

>Fix:
a  work-around is to  simply do
		set path=($path)


(!) which causes tcsh, at least, to export its default
$path to the environment as PATH.

The real problem I had with this was figuring out just why compiles
weren't working.

For consistency, I thikn we should really rework tcsh (and csh?)
to export their default "path" non-environment variable as a
sh-compatible PATH, at startup time -- just as they do
if the user does "set path =($path)".
>Release-Note:
>Audit-Trail:
>Unformatted: