default output file of gcc in the absence of -o

[Andrew Haley <aph at redhat dot com>]

Jan Beulich writes:
 > 
 > on platforms which (traditionally) do not use fixed default linker
 > output names (like a.out) we found it impossible to teach gcc to derive
 > the name so it can be properly passed to the linker; the only
 > alternative was to instead modify the asm_options spec to prevent using
 > random temporary file names (instead have the assembler produce output
 > file names derived from the input ones) and then have the linker do the
 > name derivation. (As a side note, GNU ld on Cygwin produces a.exe by
 > default, rather than a sensefully named executable as would be the
 > 'normal', that is Microsoft's, behavior - perhaps a result of the same
 > problem?) This doesn't seem ideal, though. It would thus seem rather
 > desirable to have gcc support an additional '%'-sequence for expressing
 > references to the first 'real' input file ('real' because internally
 > other things get stored as if they were input files).

I don't understand what you are trying to do.  If the compiler line
has a list of file names as input, such as

   gcc foo.o bar.c baz.o

there is no way to determine whether the ouput file should be named
foo, bar, or baz -- it makes just as much sense to name the output
file a.exe.  And if you really care what the ouput file is to be
called, you give it a name with "-o".

Also, giving the output file a name such as foo.exe if the user by
mistake fails to provide a name for the output is risky.  The user
might already have a file called foo.exe and now it's been deleted
because of a small mistake.  Okay, that would also be true if there
was a file called a.exe, but no-one should do that.

So, in my opinion this convention solves no problems and causes an
additional risk.

Andrew.