Mail Archives: cygwin/1998/09/24/17:13:58
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
program).
/Anders
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -