Object files

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

[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

[Thomas Matthews]

M.I wrote:

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.l earn.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

[Thomas Matthews]

JS wrote:

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.l earn.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

[Old Wolf]

Thomas Matthews wrote:

M.I wrote:

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

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.

[Chris Croughton]

On Wed, 13 Apr 2005 20:50:36 GMT, Thomas Matthews
<Th************ *************@s bcglobal.net> wrote:

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

[Mark McIntyre]

On Wed, 13 Apr 2005 21:33:12 +0200, in comp.lang.c , JS
<d4***@44ada.co m> wrote:

(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,progr amming is probably a good place to dsicuss it.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Walter Roberson]

In article <sl************ ******@ccserver .keris.net>,
Chris Croughton <ch***@keristor .net> wrote:

On Wed, 13 Apr 2005 20:50:36 GMT, Thomas Matthews
<Th************ *************@s bcglobal.net> wrote:

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.

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.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[Keith Thompson]

ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:
[...]

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.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.