From:	"Tony O'Bryan" <aho450s AT nic DOT smsu DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: LD looks at zip drive
Date:	Mon, 29 Dec 1997 10:09:47 -0600
Organization:	Southwest Missouri State University
Lines:	24
Message-ID:	<34A7CB4B.74C6@nic.smsu.edu>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 971229133224 DOT 28272C-100000 AT is> <6883ah$9ld AT freenet-news DOT carleton DOT ca>
Reply-To:	aho450s AT nic DOT smsu DOT edu
NNTP-Posting-Host:	marie.a32.smsu.edu
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Paul Derbyshire wrote:

> I dunno. I think it is the linker myself. The linker has a known behavior
> (bug? feature? misfeature? You decide) whre it will access any drive a
> directory on which is in the PATH, so if his Zip drive is E: and he has E:
> or E:\FOO\BAR in his path he'd get exactly what he's getting.

I had a similar problem a while ago, but I suspect the root cause is
different.  I had my C: drive split into two partitions.  I thought the
partitions would be setup as C: and D:, with drive E: being my CD-ROM. 
A later use of fdisk showed that drive D: did not exist, just that drive
C: had two partitions; but they were both still drive C:.

Whenever gcc started, Windows would reach the phantom D: drive, it would
time out; spend half an enternity running the C: drive; then spend the
other half of eternity running my E: drive, then finally finish
compiling and linking the program.  All this took place long before ld
got control.  But the underying behavior was a Windows problem (this
happened whenever using any file selection dialogue boxes in Windows,
but only the very first time after the system was booted), and was fixed
by reconfiguring my drives to eliminate the phantom D: drive and setting
my CD-ROM (the last drive in the system) as D:.

So, to summarize, perhaps he has some type of partitioning problem.

- Raw text -