From: "Andrew Crabtree" <andrewc AT rosemail DOT rose DOT hp DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Compiling in 2.8.1 vs. 2.7.2.1 - two minor problems
Date: Mon, 1 Jun 1998 09:41:45 -0700
Organization: Hewlett-Packard, Roseville
Lines: 34
Message-ID: <6kulka$8kk$1@rosenews.rose.hp.com>
References: <19980529235344 DOT AAC16281 AT ppp116 DOT cartsys DOT com>
NNTP-Posting-Host: ros51675cra.rose.hp.com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk


Nate Eldredge wrote in message
<19980529235344 DOT AAC16281 AT ppp116 DOT cartsys DOT com>...
>>First, the way gcc calls other programs changed.
>>after first compilation, when `as.exe' exists in the current
>>directory it is called by `gcc' instead of assembler program (with
>This would seem to be a bug in 2.8.1. 2.7.x uses the COMPILER_PATH

Actually, this is more of a feature.  It makes it more similar to unix style
gcc.  Type 'gcc -print-search-dirs' to see where it is searching.  It
actually uses a target/version system first, and then falls back on others.
Don't know why it is searching the current directory though.  I would avoid
the cpp, cc1, cc1plus, ld, ... names as suggested.

>>Second, in 2.7.2.1, after compilation with a command `gcc a.c -o
>>a' there were two files left: `a' and `a.exe'
>>files are identical (both are stubified).
>That also would seem to be a bug.
Nope :)  When Robert ported binutils he added a BFD for type stubbified
coff.  It used to be that many of the programs relied on raw coff image, but
not anymore.  Robert was short on disc space, so he changed binutils 2.8 to
ouput a stubified image directly.  That way you could change the compiler
specs to not call stubify.  You could just do 'gcc a.c -o a.exe' and have
the linker emit the stubbed coff directly.   If you have unix style
makefiles you would still want to output both file names so make was not
fooled into rebuilding constantly.

Both of these are documented in binutils 2.8 and gcc 2.8 and presumable
2.8.1.

Andy