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]

Re: Object files

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]

Re: Object files

JS a écrit :[color=blue]
> 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?[/color]

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]

Re: Object files

M.I wrote:[color=blue]
> 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.
>[/color]

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]

Re: Object files

JS wrote:
[color=blue]
> 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?[/color]

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]

Re: Object files

Thomas Matthews wrote:[color=blue]
> M.I wrote:[color=green]
> > .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.[/color]
>
> 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.[/color]

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]

Re: Object files

On Wed, 13 Apr 2005 20:50:36 GMT, Thomas Matthews
<Thomas_Matthew sSpamBotsSuck@s bcglobal.net> wrote:
[color=blue]
> You can't give anybody a '.o' file.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> What's worse is that the object file may not be portable across
> platforms either.[/color]

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).
[color=blue]
> Before you recommend sharing of '.o' files, please have more
> information ready or state the warning.[/color]

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

Chris C

[Mark McIntyre]

Re: Object files

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

(reordered slightly)
[color=blue]
>Why does the code that I write in main.c suddenly become a .o file?[/color]

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.
[color=blue]
>I read this in a make file:[/color]

'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]

Re: Object files

In article <slrnd5s5ki.qql .chris@ccserver .keris.net>,
Chris Croughton <chris@keristor .net> wrote:[color=blue]
>On Wed, 13 Apr 2005 20:50:36 GMT, Thomas Matthews
> <Thomas_Matthew sSpamBotsSuck@s bcglobal.net> wrote:[/color]
[color=blue][color=green]
>> 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.[/color][/color]
[color=blue]
>Which century are you in? That may have been true 20 years ago, but
>these days we have stardards for such things.[/color]

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]

Re: Object files

roberson@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:
[...][color=blue]
> 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.[/color]

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) kst-u@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.

[Simon]

Re: Object files

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

[Chris Croughton]

Re: Object files

On 15 Apr 2005 22:01:52 GMT, Walter Roberson
<roberson@ibd.n rc-cnrc.gc.ca> wrote:
[color=blue]
> In article <slrnd60afk.es8 .chris@ccserver .keris.net>,
> Chris Croughton <chris@keristor .net> wrote:[color=green]
>>On 14 Apr 2005 22:53:24 GMT, Walter Roberson
>> <roberson@ibd.n rc-cnrc.gc.ca> wrote:[/color]
>[color=green][color=darkred]
>>>>On Wed, 13 Apr 2005 20:50:36 GMT, Thomas Matthews
>>>> <Thomas_Matthew sSpamBotsSuck@s bcglobal.net> wrote:[/color][/color]
>[color=green][color=darkred]
>>>>> 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.[/color][/color]
>[color=green]
>>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.[/color]
>
> Did Thomas say that you can't distribute object files or executables?[/color]

Yes:

--------------------------------------------------------------------
From: Thomas Matthews <Thomas_Matthew sSpamBotsSuck@s bcglobal.net>
Newsgroups: comp.lang.c
Subject: Re: Object files
Date: Wed, 13 Apr 2005 20:50:36 GMT
Reply-To: Thomas_Matthews SpamBotsSuck@sb cglobal.net

M.I wrote:[color=blue]
> 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.
>[/color]

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.
[color=blue]
> Re-read what he said: he said that some things *might* not be
> compatible with other apparently similar things.[/color]

He then went on to say that they /may/ not be compatible, but he also
made the blanket statement.
[color=blue]
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
>>> All parts of Thomas's statement have happened to me, and it was
>>> certainly less than 20 years ago.[/color][/color]
>[color=green]
>>On any common system?[/color]
>
> Is gcc common? ("Is God famous?")[/color]

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