From: "Tim Van Holder" To: Subject: RE: Where does gcc -o foo make foo.exe Date: Sun, 14 Jan 2001 13:56:51 +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 HAA13555 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 > 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. Not really, you can just add AC_EXEEXT to configure.in and @EXEEXT@ to Makefile.in and it will continue to DTRT on all platforms. But then we get into the same discussion we had with gettext: should maintainers of DJGPP packages be required to have autoconf/automake. My feelings on this are a definite YES, but most others on this list seem to disagree with me (mostly because automake/aclocal requires perl, which is a non-trivial package). > 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. I thought system actually checked a file was executable. If it doesn't, Anything May Happen(tm). > Anyway, even if libc refuses to run the program, the command in Makefile > will fail, which isn't what we want. I thought system()/spawn() would skip foo if it wasn't executable, and then find foo.exe and run that. > 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. But then make clean wouldn't remove foo.exe, as it doesn't know about .exe. I think adjusting ld would be a good TEMPORARY solution; DJGPP package maintainers should submit patches to the GNU maintainers for packages that don't use automake or don't use AC_EXEEXT properly. Also, could someone check whether the DJGPP package for autoconf 2.13 works with 'foo.exe only' if ac_exeext=.exe in config.site? If that's the case, existing configure scripts will still work; only Makefiles will have a problem (they'll try to rebuild each executable when you type make), but that's more of a nuisance than real breakage. I've been using a '.exe only' setup for over a year now (I don't even use djgpp.djl, just ld's builtin script), with only the @EXEEXT@ in makefiles thing as a minor nuisance.