Re: default output file of gcc in the absence of -o

["Jan Beulich" <JBeulich at novell dot com>]

Take for given that the convention is that way. The point is not to make
gcc default to that, but to permit the specs to be written to conform to
that convention for certain platforms. I for myself consider it rather
useful especially when there is just a single input file - i.e. "gcc
test.c" would result in test or test.some-extension rather than a.out,
a.exe, or whetherever else hard coded output name defaults exist, and I
am appearantly not alone since I have others requesting this
functionality for our platform.

Thanks, Jan

>>> Andrew Haley <aph@redhat.com> 27.01.03 12:55:02 >>>
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.