Date:	Sun, 14 Jan 2001 14:00:23 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Where does gcc -o foo make foo.exe
In-Reply-To:	<NEBBIOJNGMKPNOBKHCGHIEJBCAAA.tim.van.holder@pandora.be>
Message-ID:	<Pine.SUN.3.91.1010114135136.26583E-100000@is>
MIME-Version:	1.0
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

On Sun, 14 Jan 2001, Tim Van Holder wrote:

> Alternatively, automake'd
> packages will require adding AC_EXEEXT to configure.in and re-running
> autoconf and automake. In any case, automake'd Makefiles should be doing
> The Right Thing(tm) already; if they're not, it indicates a problem with
> configure.in.
> Non-automake'd makefiles will need manual adjusting. But then again, those
> probably already used per-platform variations, so minor changes to the
> existing Makefile.dj2 should not be too big a deal.

Most packages which support DJGPP in the official distribution use the 
configure script (Emacs and Make are the notable exceptions), so there's 
no Makefile.dj2 to hack.  If the configure script and Makefile.in don't 
DTRT, you are screwed.

> (though if it's a zero-byte file, or a file containing 'dummy for 
> foo.exe', I doubt libc will try to execute it.

I think libc will either invoke COMMAND.COM to run these ``programs'' or 
pass them to DOS, with very sad results (since COMMAND.COM and DOS will 
happily run _anything_).  You can try it and see what happens.

Anyway, even if libc refuses to run the program, the command in Makefile 
will fail, which isn't what we want.

> Best I can do is to make sure autoconf and automake DTRT; Cygnus configure
> already does, I think.

If we don't want to accept the consequences of getting rid of the 
unstubified COFF executables, and don't have resources to fix all the 
popular packages out there that rely on them, we had better not make
this change in ld.  A bit of disk waste hurts much less than broken 
packages, especially since "make clean" removes all that junk.

- Raw text -