default output file of gcc in the absence of -o

default output file of gcc in the absence of -o

[Jan Beulich]

Hello,

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

Looking forward to opinions,
Jan

default output file of gcc in the absence of -o

[Andrew Haley]

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.

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

[Jan Beulich]

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.