From: "Tim Van Holder" To: Subject: Re: Where does gcc -o foo make foo.exe Date: Sun, 14 Jan 2001 10:37:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id EAA06260 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 > Even if Autoconf is fixed, what do we do about all the Makefile's out > there which have "foo", not "foo$EXE_EXT" as their targets? Well, autoconf now uses AC_EXEEXT automatically when a compiler check is done (at least, it did in 2.49a; can't be really sure it will be this way in the 2.50 release). Unfortunately, automake still requires seeing an explicit AC_EXEEXT call in configure.in. Once autoconf 2.50 is released, I'll probably make a DJGPP package of the current CVS automake as well; if it still requires AC_EXEEXT, I'll hack it to look for the macro autoconf invokes which runs AC_EXEEXT. 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. > We could make ld.exe create an empty `foo', but I suspect that at least > some Makefile's will actually try to run `foo' (I remember seeing > "GO32-V2" in the DOS box's caption bar when some packages build). Yes, usually they use ./ . This is perfectly acceptable if we generate foo.exe, and even if we let ld produce a coff-go32-exe named foo, but not if we have a fake foo (though if it's a zero-byte file, or a file containing 'dummy for foo.exe', I doubt libc will try to execute it. > So I'm afraid getting rid of producing the extensionless program will > break too many packages that have integrated DJGPP support. Someone(tm) > will have to fix all those as well. Best I can do is to make sure autoconf and automake DTRT; Cygnus configure already does, I think.