gcc produces foo.exe, not foo

Anders Norlander anorland@hem2.passagen.se
Thu Sep 24 04:01:00 GMT 1998

Mumit Khan wrote:
> On Wed, 23 Sep 1998, Arne Glenstrup wrote:
> >
> > The problem is that it seems that when running
> >
> >   gcc -o foo foo.c
> >
> > it produces not a file named foo, but a file named foo.exe. This has
> > caused me problems when writing a Makefile somewhat like
> >
> >   bar: foo.c
> >           gcc -o foo foo.c
> >           mv foo bar
> >
> > because it complains when trying to mv file foo.
> >
> > What is the standard way of circumventing this problem? Simply writing
> >
> >           mv foo.exe bar.exe
> >
> All my local configuration systems check for executable extension and
> define a variable such as exeext to either the extension or "" if none
> is added by default. Lots of GNU Makefiles are beginning to use this
> as well. The Makefile rules look like the following:
>   PROGRAMS = bar$(exeext)
>   bar$(exeext): foo.c
>         $(CC) -o foo foo.c
>         mv foo$(exeext) bar$(exeext)
> Rather ugly, but currently the only usable solution.
> As for the rationale for adding the automatic .exe, I'm somewhat in
> favor of, if not thrilled by, such "native compliance"; for mingw32, it
> makes perfect sense (must have .exe to jive with native system and also
> be executable by native shell); for cygwin32, bash can run programs
> with or without .exe, but have trouble when running with native shell.

Just an interesting fact. Executables can actually have any extension
*except* "" in win32. The limitation of the ".exe" extension
is not built in the kernel, but in the shell, i.e it is possible
to start processes with any extension via `CreateProcess' but
not with ShellExecute (which instead tries to find an associated

For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

More information about the Cygwin mailing list