From: "Tony O'Bryan" 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: <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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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.