Date: Sat, 13 Jan 2001 19:58:38 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Mark E." Message-Id: <9628-Sat13Jan2001195838+0200-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6 CC: djgpp-workers AT delorie DOT com In-reply-to: <3A604169.19279.186908@localhost> (snowball3@bigfoot.com) Subject: Re: Where does gcc -o foo make foo.exe References: <3A5F49FE DOT 11625 DOT 45D878 AT localhost> (snowball3 AT bigfoot DOT com) <3A604169 DOT 19279 DOT 186908 AT localhost> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Mark E." > Date: Sat, 13 Jan 2001 11:52:09 -0500 > > > > Right. But DJGPP overrides LINK_COMMAND_SPEC in gcc's djgpp.h to use > > > djgpp.djl (which sets the target to coff-go32) and then call stubify on the > > > result. Any chance we can now finally agree to dispense with this? > > > > Why would we want to dispense with that? > > It would cut out an unneccessary step during linking. If you mean the stubify step, then I think before we toss it, we need to have a satisfactory solution to these two problems: - "gcc -o foo" should create both foo and foo.exe, to make Autoconf and Make happy; - the stub used to produce the .exe program should be the same stub distributed with the installed djdev (I didn't forget the GO32STUB feature, I just don't think it's reliable enough, because it depends on DJGPP.ENV). It would also be nice to solve the problem with extra 2KB of garbage in the executables produced by ld.exe, but that's a minor nuisance (and maybe it's already solved, I don't remember).