Object files

J

JS

I am a bit confused about the meaning of object files (.o).

I read this in a make file:

lotto: main.o init.o select.o sort.o display.o
gcc main.o init.o select.o sort.o display.o -o lotto

main.o: main.c lotto.h
gcc -c main.c

....etc.

Why does the code that I write in main.c suddenly become a .o file?
 
M

M.I

The followoing line tells make to compile your main.c file into main.o.

main.o: main.c lotto.h
gcc -c main.c
..c file are source files in human reabable form, whereas .o file
contains the instruction for linker which creates an executable file
out of object file, .o file is not close to human readable form. Also
if you have some code that you want to share or sell but you don't want
the client to see your source code you can give them .o files.
 
H

hibiki

JS a écrit :
I am a bit confused about the meaning of object files (.o).

I read this in a make file:

lotto: main.o init.o select.o sort.o display.o
gcc main.o init.o select.o sort.o display.o -o lotto

main.o: main.c lotto.h
gcc -c main.c

...etc.

Why does the code that I write in main.c suddenly become a .o file?

These are temporary files that are not linked together.
I don't really know how to explain that...
These files are not executable, they contain the compiled code of the .c
file.
The compiler, first : make the binary code for each .c file and then :
put all these parts together to make a real executable.

This allows the developer to proceed in several parts/files (in a
development team, for example)

When you have few files, for example a main.c, you can compile and link
it directy by using : gcc main.c -o main

--
Salutations,

Joachim Naulet

06 14 90 06 21
http://jnaulet.no-ip.com
 
T

Thomas Matthews

M.I said:
The followoing line tells make to compile your main.c file into main.o.

main.o: main.c lotto.h
gcc -c main.c
.c file are source files in human reabable form, whereas .o file
contains the instruction for linker which creates an executable file
out of object file, .o file is not close to human readable form. Also
if you have some code that you want to share or sell but you don't want
the client to see your source code you can give them .o files.

You can't give anybody a '.o' file. The '.o' file is an output
that depends on the brand of compiler you use. One compiler's
object file may not be compatible with another brand of compiler,
linker or another version of the same compiler.

What's worse is that the object file may not be portable across
platforms either.

Before you recommend sharing of '.o' files, please have more
information ready or state the warning.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library
 
T

Thomas Matthews

JS said:
I am a bit confused about the meaning of object files (.o).

I read this in a make file:

lotto: main.o init.o select.o sort.o display.o
gcc main.o init.o select.o sort.o display.o -o lotto

main.o: main.c lotto.h
gcc -c main.c

...etc.

Why does the code that I write in main.c suddenly become a .o file?

Object files, not a topic of this newsgroup, are an output
from a compiler (translator).

Some compilers can create executables directly from
source code. Other compilers create intermediate files
known as "object" files (with common extensions of '.o'
or '.obj'). The object files must be linked together
to form an executable.

One rationale about using object files is to reduce
the time building a program. In general, object files
are faster to process than translating source code.
If the source for the object file has not changed,
there is no need to compile the source again, thus
saving build time.

A common tool used to track and process these
dependencies (i.e. executable depends on one or
more objects; object depends on one or more
source files; source depends on zero or more
headers) is called "Make" and its instructions
are in a "makefile". Both of which are off-topic
in this newsgroup. Basically, if the dependency
is newer than the target, the target is recreated
from the dependency.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library
 
O

Old Wolf

Thomas said:
You can't give anybody a '.o' file. The '.o' file is an output
that depends on the brand of compiler you use. One compiler's
object file may not be compatible with another brand of compiler,
linker or another version of the same compiler.

Before you recommend sharing of '.o' files, please have more
information ready or state the warning.

Some compiler vendors make an effort to have a common ABI and
interchangeable object files. You should consult the compiler
documentation to determine if distributing code via static
libraries is going to work. (A static library is merely zero
or more object files stored one after the other in a single
file). For example, GCC's linker is capable of reading just
about any compiler's object files, via the GNU libBFD library.

It's not unheard of for software to be distributed as .lib
or .a files.
 
C

Chris Croughton

You can't give anybody a '.o' file.

Put floppy disk in computer.
Copy *.o to floppy disk.
Take floppy disk out of computer, give it to someone.

I've just given someone a load of .o files.

"You can't give anybody a '.o' file" is just plain untrue.
The '.o' file is an output that depends on the brand of compiler you
use. One compiler's object file may not be compatible with another
brand of compiler, linker or another version of the same compiler.

Which century are you in? That may have been true 20 years ago, but
these days we have stardards for such things.

It is very common in the commercial world to do "binary releases"
of software in object or library (collection of object files) form, to
protect the source, all you have to do is to make sure that you compile
them with compatible software to that of the person using them.

In practice, most compilers in the Windows world produce compatible
object files at least for C (C++ name mangling is a different matter),
and they do for a single platform in the Unix world as well. How do you
think standard libraries work? On my Debian GNU/Linux system I have
dozens (at least) of libraries supplied in object form, they don't need
recompiling if I install a new version of the compiler (or even another
compiler on that system). Even Gentoo, which is a GNU/Linux
distribution where almost everything is compiled from source by the
installer, distributes object files and libraries of object files to get
started (to build an application you need to have the standard libraries
and object files first before you can compile it).

It's called "binary compatibility", and is something compiler and
library writers spend a lot of time making sure that they get right so
that people don't have to build everything from source all the time.
What's worse is that the object file may not be portable across
platforms either.

So you produce them for the appropriate platform. At work we produce
object files for Windows, GNU/Linux-x86 and ARM (which has a published
standard ABI) for distribution, you are given (sold) the version
appropriate for your use. If we had customers who used other systems we
would produce the object files for those as well (we might charge a
'setup' fee if it meant us buying extra hardware or software to produce
them).
Before you recommend sharing of '.o' files, please have more
information ready or state the warning.

How would you go about giving someone code for them to use but they
aren't allowed to see?

Chris C
 
M

Mark McIntyre

On Wed, 13 Apr 2005 21:33:12 +0200, in comp.lang.c , JS

(reordered slightly)
Why does the code that I write in main.c suddenly become a .o file?

because you compiled it to an object. This is typically a
machine-language set of instructions which represent your code. After
its been compiled, most systems require it to also be linked with
libraries of other objects, to form a complete executable. These other
objects contain machine instructions for stuff like disk io. screen
interaction and so on.
I read this in a make file:

'make' is a tool to automate the compilation and linking process.
Unfortunately its also offtopic here, as its platform-specific and
different make tools work differently. I believe you're on linux or
unix so comp.unix,programming is probably a good place to dsicuss it.
 
W

Walter Roberson

On Wed, 13 Apr 2005 20:50:36 GMT, Thomas Matthews
Which century are you in? That may have been true 20 years ago, but
these days we have stardards for such things.

In this group, it is common to use colourful expressions such as
"nose demons" with respect to undefined behaviour (no matter how
commonly implemented.)

*Someone* may have standards for formats such as ELF and COFF,
but it isn't the ISO or ANSI subgroups that produced the specification
for C.

This group often touches upon unusual behaviours that can occur
on embedded systems, systems with unusual numbers of bits per
register, and other sports of nature that are none-the-less
compatible with the C standard.

All parts of Thomas's statement have happened to me, and it was
certainly less than 20 years ago.
 
C

Chris Croughton

In this group, it is common to use colourful expressions such as
"nose demons" with respect to undefined behaviour (no matter how
commonly implemented.)

And just how commonly implemented are node demons?
*Someone* may have standards for formats such as ELF and COFF,
but it isn't the ISO or ANSI subgroups that produced the specification
for C.

So? Saying as a blanket statement that you can't distribute object
files is plain wrong, because people can and do (every Linux system --
heck all of the kernel modules are object files; every Windows compiler;
every 'binary only' SDK). Indeed, it makes as little sense as saying
"you can't distribute executable files" as a blanket statement.
This group often touches upon unusual behaviours that can occur
on embedded systems, systems with unusual numbers of bits per
register, and other sports of nature that are none-the-less
compatible with the C standard.

All parts of Thomas's statement have happened to me, and it was
certainly less than 20 years ago.

On any common system? For that matter, plenty of uncommon systems get
object files distributed with them (a lot of the ARM embedded systems
use operating systems with only object files distributed; all of the
Symbian-based mobile phones do the same (Nokia, Sony Eriksson, etc.);
any embedded systems using WinCE...).

Chris C
 
W

Walter Roberson

On 14 Apr 2005 22:53:24 GMT, Walter Roberson
So? Saying as a blanket statement that you can't distribute object
files is plain wrong, because people can and do (every Linux system --
heck all of the kernel modules are object files; every Windows compiler;
every 'binary only' SDK). Indeed, it makes as little sense as saying
"you can't distribute executable files" as a blanket statement.

Did Thomas say that you can't distribute object files or executables?

Re-read what he said: he said that some things *might* not be
compatible with other apparently similar things. If you do happen
to get compatibility, that's a bonus. But it doesn't fall within
the scope of the C standard and thus is not something that someone
trying to write portable C should count on.
On any common system?

Is gcc common? ("Is God famous?")
 
K

Keith Thompson

Did Thomas say that you can't distribute object files or executables?

Re-read what he said: he said that some things *might* not be
compatible with other apparently similar things. If you do happen
to get compatibility, that's a bonus. But it doesn't fall within
the scope of the C standard and thus is not something that someone
trying to write portable C should count on.

Thomas also said:

] You can't give anybody a '.o' file.

though I think that was just a fairly harmless overstatement.
 
S

Simon

Do note that, confusingly for some, these "object files" have nothing
to do whatsoever with "object-oriented programming" a la Java or C++.
 
C

Chris Croughton

Did Thomas say that you can't distribute object files or executables?

Yes:

--------------------------------------------------------------------
From: Thomas Matthews <[email protected]>
Newsgroups: comp.lang.c
Subject: Re: Object files
Date: Wed, 13 Apr 2005 20:50:36 GMT
Reply-To: (e-mail address removed)

M.I said:
The followoing line tells make to compile your main.c file into main.o.

main.o: main.c lotto.h
gcc -c main.c
.c file are source files in human reabable form, whereas .o file
contains the instruction for linker which creates an executable file
out of object file, .o file is not close to human readable form. Also
if you have some code that you want to share or sell but you don't want
the client to see your source code you can give them .o files.

You can't give anybody a '.o' file. The '.o' file is an output
that depends on the brand of compiler you use. One compiler's
object file may not be compatible with another brand of compiler,
linker or another version of the same compiler.
--------------------------------------------------------------------

That's exactly what I was originally commenting about, it was wrong.
W R O N G. Incorrect.
Re-read what he said: he said that some things *might* not be
compatible with other apparently similar things.

He then went on to say that they /may/ not be compatible, but he also
made the blanket statement.
If you do happen
to get compatibility, that's a bonus. But it doesn't fall within
the scope of the C standard and thus is not something that someone
trying to write portable C should count on.

If you want it to be totally compatible, you can't count on anything,
including counting on there being a working standard-compliant C
compiler for your target system. There are only degrees of
compatibility, and the degree to which it needs to be compatible
determines what you can do.
Is gcc common? ("Is God famous?")

Fairly. But has gcc actually broken object compatibility between
compiler releases (on the same system) in this century? The transition
from EGCS to GCC 2.95 was at the end of July 1999, and I don't recall
that breaking C object compatibility (and certainly I've linked 2.95.x
and 3.x C object files with no problems).

(I do have problems with some other languages, like C++, and at some
point debugger information changed, but straight C hasn't been a problem
with GCC for many years.)

Re. your second question, I know a number of people who would say
'infamous' (depending which particular God you had in mind)...

Chris C
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top