delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/01/14/07:55:52

From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: RE: Where does gcc -o foo make foo.exe
Date: Sun, 14 Jan 2001 13:56:51 +0100
Message-ID: <NEBBIOJNGMKPNOBKHCGHOEJDCAAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
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: <Pine.SUN.3.91.1010114135136.26583E-100000@is>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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

> 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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019