a.out when compiling

a.out when compiling

Post by Andrew Davi » Wed, 27 Sep 2000 04:00:00



I remember a long time back reading a package description saying something
along the lines of "a.out compatibility" and it "being replaced with elf".
Everytime I compile anything, it shows up in a.out format instead of .c or
.cc or .C. Anyone know what package it is that does that so I can remove it?
I'm running RH 6.2...

Andrew Davis
Sr. UNIX and Linux Systems Admin.
Flashcom, INC.

 
 
 

a.out when compiling

Post by Alan Shutk » Wed, 27 Sep 2000 04:00:00



> I remember a long time back reading a package description saying something
> along the lines of "a.out compatibility" and it "being replaced with elf".
> Everytime I compile anything, it shows up in a.out format instead of .c or
> .cc or .C. Anyone know what package it is that does that so I can remove it?

This is actually just a confusion caused by the same name being used
for different things.

There _used_ to be a binary format called a.out used in Unix and
Linux.  The default name for executables created by the compiler was
also "a.out".  One was named from the other, but nowadays, the default
name for executables remains "a.out" and the only way you can tell the
format of the actual executable is to run file on it.

[15:08:33] wesley:~ $ echo 'int main(void){return 0;}' > file.c
[15:08:43] wesley:~ $ gcc file.c
[15:08:53] wesley:~ $ ls -lrt | tail -2
-rw-rw-r--    1 ats      ats            26 Sep 26 15:08 file.c
-rwxrwxr-x    1 ats      ats         13178 Sep 26 15:08 a.out
[15:09:01] wesley:~ $ file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped

So, really, you _are_ getting the right executable format.  You have
to go through some contortions to get the older executable format on
RHL 6.2, and it's not going to happen by accident.  

If you'd like to change the name of your executables, use the -o
option to gcc:

gcc file.c -o file

--

45 days, 20 hours, 29 minutes, 17 seconds till we run away.
How can you work when the system's so crowded?

 
 
 

a.out when compiling

Post by Johan Kullsta » Wed, 27 Sep 2000 04:00:00



> I remember a long time back reading a package description saying something
> along the lines of "a.out compatibility" and it "being replaced with elf".
> Everytime I compile anything, it shows up in a.out format

is it making a file named "a.out" or is it in "a.out binary format"?
afaik a.out is some variant on COFF.  it'd have been a lot easier if
the latter sense had been called LCOFF (for linux COFF) or something.
the a.out binary format has a perhaps unfortunate name since it's easy
to confuse with the default output file name from the C compiler.  i
suspect (because you mention using redhat 6.2) that the binary file is
named "a.out" yet is ELF but not an "a.out binary".  try running "file
a.out".

here is what i've got on my redhat 6.2 system.  the file srt.c is a
tiny C program i happened to have lying around.

sysengr(~/Tmp)$ gcc -O2 srt.c

this creates a file named "a.out"

sysengr(~/Tmp)$ file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped

thus a.out is really ELF.  yes it's confusing.

Quote:> instead of .c or .cc or .C.

the .c files are *inputs* to the C compiler.  the compiler never
creates them.

Quote:> Anyone know what package it is that does that so I can remove it?
> I'm running RH 6.2...

HTH

--
J o h a n  K u l l s t a m

sysengr

 
 
 

a.out when compiling

Post by Andrew Davi » Thu, 28 Sep 2000 04:00:00


My apologies... my head was moving faster than my hands. I understand that
a.out was the old-school way of doing things and that it was replaced with
ELF format. I also know that when recompiling my kernel I can include or
exclude support for a.out binaries, forcing my system to use ELF binaries
only. Further I know that when compiling I can use the -o option to pass a
filename through; something like
gcc -o program.o program.c. Lastly I know that most distributions ship with
compatibility libraries for backwards compatibility, so I was wondering if
there is a way (maybe by excluding a package or library) of having my
compilier automatically create output as *.o vs. a.out. I have yet to find
anything like a gcc.conf to do it  :)  Also, I'm curious if removing a.out
binary support from my kernel will cause all compiled programs to output in
*.o format?
If you're totally confused by this... then let me explain my problem. We
have a piece of s/w here to which we run scripts against for reports. I have
three different .c program housed in the same directory (and they can't be
relocated). When my script runs it compiles each one individually and then
runs them (the .c programs change daily and have to be recompiled daily). My
problem is that I need them to compile to uniqueprogram.o instead of a.out,
thus NOT overwriting each other. I am limited by being unable to move the
programs into different directories or symlinking them. So... I am looking
for a way to have my compiler produce program.o binaries by default instead
of a.out.

Thanks

    Andrew Davis
    Sr. Unix Systems Administrator - Flashcom, Inc.
    877-352-7426, ext. 2203


    Never Underestimate the Power of
    Stupid People in Large Groups



> > I remember a long time back reading a package description saying
something
> > along the lines of "a.out compatibility" and it "being replaced with
elf".
> > Everytime I compile anything, it shows up in a.out format

> is it making a file named "a.out" or is it in "a.out binary format"?
> afaik a.out is some variant on COFF.  it'd have been a lot easier if
> the latter sense had been called LCOFF (for linux COFF) or something.
> the a.out binary format has a perhaps unfortunate name since it's easy
> to confuse with the default output file name from the C compiler.  i
> suspect (because you mention using redhat 6.2) that the binary file is
> named "a.out" yet is ELF but not an "a.out binary".  try running "file
> a.out".

> here is what i've got on my redhat 6.2 system.  the file srt.c is a
> tiny C program i happened to have lying around.

> sysengr(~/Tmp)$ gcc -O2 srt.c

> this creates a file named "a.out"

> sysengr(~/Tmp)$ file a.out
> a.out: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically

linked (uses shared libs), not stripped

- Show quoted text -

> thus a.out is really ELF.  yes it's confusing.

> > instead of .c or .cc or .C.

> the .c files are *inputs* to the C compiler.  the compiler never
> creates them.

> > Anyone know what package it is that does that so I can remove it?
> > I'm running RH 6.2...

> HTH

> --
> J o h a n  K u l l s t a m

> sysengr

 
 
 

a.out when compiling

Post by Johan Kullsta » Thu, 28 Sep 2000 04:00:00



> My apologies... my head was moving faster than my hands. I understand that
> a.out was the old-school way of doing things and that it was replaced with
> ELF format. I also know that when recompiling my kernel I can include or
> exclude support for a.out binaries, forcing my system to use ELF binaries
> only.

ok.

Quote:> Further I know that when compiling I can use the -o option to pass a
> filename through; something like
> gcc -o program.o program.c. Lastly I know that most distributions ship with
> compatibility libraries for backwards compatibility, so I was wondering if
> there is a way (maybe by excluding a package or library) of having my
> compilier automatically create output as *.o vs. a.out. I have yet to find
> anything like a gcc.conf to do it  :)  Also, I'm curious if removing a.out
> binary support from my kernel will cause all compiled programs to output in
> *.o format?

again, this has *nothing* to do with the a.out binary format vs ELF.
your problem is with the *name* a.out being the default output file
from the C compiler.  ELF and a.out binaries are completely unrelated
issue.  the binary format and the file name are *two* *different*
*things*.

Quote:> If you're totally confused by this... then let me explain my problem. We
> have a piece of s/w here to which we run scripts against for reports. I have
> three different .c program housed in the same directory (and they can't be
> relocated). When my script runs it compiles each one individually and then
> runs them (the .c programs change daily and have to be recompiled daily). My
> problem is that I need them to compile to uniqueprogram.o instead of a.out,
> thus NOT overwriting each other. I am limited by being unable to move the
> programs into different directories or symlinking them. So... I am looking
> for a way to have my compiler produce program.o binaries by default instead
> of a.out.

you can use -c

gcc -c foo.c

will produce the object file foo.o.  foo.o isn't executable though.

gcc, like *every* unix C compiler, generates a file *named* "a.out"
(and this file may well be in ELF despite any association you have
with its name) by default.  you can override this by -o <filename>.
if you don't like this, i have only one suggestion, use the source
luke!  get the gcc sources, hack them and recompile.

> Thanks

>     Andrew Davis
>     Sr. Unix Systems Administrator - Flashcom, Inc.
>     877-352-7426, ext. 2203


>     Never Underestimate the Power of
>     Stupid People in Large Groups




> > > I remember a long time back reading a package description saying
> something
> > > along the lines of "a.out compatibility" and it "being replaced with
> elf".
> > > Everytime I compile anything, it shows up in a.out format

> > is it making a file named "a.out" or is it in "a.out binary format"?
> > afaik a.out is some variant on COFF.  it'd have been a lot easier if
> > the latter sense had been called LCOFF (for linux COFF) or something.
> > the a.out binary format has a perhaps unfortunate name since it's easy
> > to confuse with the default output file name from the C compiler.  i
> > suspect (because you mention using redhat 6.2) that the binary file is
> > named "a.out" yet is ELF but not an "a.out binary".  try running "file
> > a.out".

> > here is what i've got on my redhat 6.2 system.  the file srt.c is a
> > tiny C program i happened to have lying around.

> > sysengr(~/Tmp)$ gcc -O2 srt.c

> > this creates a file named "a.out"

> > sysengr(~/Tmp)$ file a.out
> > a.out: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically
> linked (uses shared libs), not stripped

> > thus a.out is really ELF.  yes it's confusing.

> > > instead of .c or .cc or .C.

> > the .c files are *inputs* to the C compiler.  the compiler never
> > creates them.

> > > Anyone know what package it is that does that so I can remove it?
> > > I'm running RH 6.2...

> > HTH

> > --
> > J o h a n  K u l l s t a m

> > sysengr

--
J o h a n  K u l l s t a m

sysengr
 
 
 

a.out when compiling

Post by James C. Georga » Sat, 07 Oct 2000 09:43:36



> My apologies... my head was moving faster than my hands. I understand that
> a.out was the old-school way of doing things and that it was replaced with
> ELF format. I also know that when recompiling my kernel I can include or
> exclude support for a.out binaries, forcing my system to use ELF binaries
> only. Further I know that when compiling I can use the -o option to pass a
> filename through; something like
> gcc -o program.o program.c. Lastly I know that most distributions ship with
> compatibility libraries for backwards compatibility, so I was wondering if
> there is a way (maybe by excluding a package or library) of having my
> compilier automatically create output as *.o vs. a.out. I have yet to find
> anything like a gcc.conf to do it  :)  Also, I'm curious if removing a.out
> binary support from my kernel will cause all compiled programs to output in
> *.o format?
> If you're totally confused by this... then let me explain my problem. We
> have a piece of s/w here to which we run scripts against for reports. I have
> three different .c program housed in the same directory (and they can't be
> relocated). When my script runs it compiles each one individually and then
> runs them (the .c programs change daily and have to be recompiled daily). My
> problem is that I need them to compile to uniqueprogram.o instead of a.out,
> thus NOT overwriting each other. I am limited by being unable to move the
> programs into different directories or symlinking them. So... I am looking
> for a way to have my compiler produce program.o binaries by default instead
> of a.out.

> Thanks

>     Andrew Davis
>     Sr. Unix Systems Administrator - Flashcom, Inc.
>     877-352-7426, ext. 2203


>     Never Underestimate the Power of
>     Stupid People in Large Groups

The easiest way to do this is to write a script like this:

----------------------------------------

#!/bin/sh

# Compile my three projects to executable form:

gcc program1.c -o program1.o

gcc program2.c -o program2.o

gcc program3.c -o program3.o

# end of script.

---------------------------------------

Of course, you can use shell commands to make this more general.

A better solution would be to write a makefile to control the compilation
process.

----------------------------------

# Makefile for my three projects.

all: prog1.o prog2.o prog3.o

prog1.o: prog1.c
    gcc prog1.c -o prog1.o

prog2.o: prog2.c
    gcc prog2.c -o prog2.o

prog3.o: prog3.c
    gcc prog3.c -o prog3.o

# End of MakeFile

---------------------------------

This will only recompile a program when it's .c file changes, thereby saving
compile time and system resources. Again, there is lots of syntax you can use
in a makefile to make it more general and less readable.

As a side note, .o is the default extension for a compiled object module, which
is one step below a linked executable program. It'd  probably be a good idea to
choose some other naming convention for your executables ( like dropping the
suffix altogether ), to avoid confusion.

Note that gcc actually generates temporary .o ( object ) files as an
intermediate step in the above commands, which it then erases when it's done.
So the actual sequence is more like:

    gcc -c program1.c -o /tmp/tempororyfilename.o
    gcc /tmp/tempororyfilename.o -o program1.o
    rm /tmp/tempororyfilename.o

I find the second line a bit cryptic, at first glance, since it looks like
you're dealing with two object modules, instead of an object module and an
executable program.

Hope this helps.

        /\V

 
 
 

a.out when compiling

Post by Michael Meissne » Tue, 24 Oct 2000 13:06:07




> > I remember a long time back reading a package description saying something
> > along the lines of "a.out compatibility" and it "being replaced with elf".
> > Everytime I compile anything, it shows up in a.out format

> is it making a file named "a.out" or is it in "a.out binary format"?
> afaik a.out is some variant on COFF.  it'd have been a lot easier if
> the latter sense had been called LCOFF (for linux COFF) or something.
> the a.out binary format has a perhaps unfortunate name since it's easy
> to confuse with the default output file name from the C compiler.  i
> suspect (because you mention using redhat 6.2) that the binary file is
> named "a.out" yet is ELF but not an "a.out binary".  try running "file
> a.out".

Ummm no, the A.OUT object file format is not a variant on COFF.  A.OUT format
predates COFF, and IIRC was the object file format used in Version 7 (late
1970's) of UNIX (it may have been the object file format for Version 6 as well,
I don't have the wall of UNIX manuals for each varient any more).  COFF was
introduced outside of Bell Labs in System V (late 1980's), and while is an
improvement over a.out format, is still crippled in many ways.  Other vendors
have their own varients of COFF, including Mips/Compaq called ECOFF, and IBM
which calls theirs XCOFF.  ELF and the debug format DWARF were introducted
outside of Bell Labs in System V.4 (early to mid 1990's).  Intel ia-32 (ie,
x86) systems went from a.out format to ELF (no COFF), while many of the other
machine types Linux runs on used COFF compilers (no a.out) and now all use ELF.

--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA