Object files

Discussion in 'C Programming' started by JS, Apr 13, 2005.

  1. JS

    JS Guest

    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?
    JS, Apr 13, 2005
    #1
    1. Advertising

  2. JS

    M.I Guest

    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.
    M.I, Apr 13, 2005
    #2
    1. Advertising

  3. JS

    hibiki Guest

    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
    hibiki, Apr 13, 2005
    #3
  4. 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.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
    Thomas Matthews, Apr 13, 2005
    #4
  5. 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.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
    Thomas Matthews, Apr 13, 2005
    #5
  6. JS

    Old Wolf Guest

    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.
    Old Wolf, Apr 14, 2005
    #6
  7. On Wed, 13 Apr 2005 20:50:36 GMT, Thomas Matthews
    <> 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
    Chris Croughton, Apr 14, 2005
    #7
  8. On Wed, 13 Apr 2005 21:33:12 +0200, in comp.lang.c , JS
    <> 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,programming 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 =----
    Mark McIntyre, Apr 14, 2005
    #8
  9. In article <>,
    Chris Croughton <> wrote:
    >On Wed, 13 Apr 2005 20:50:36 GMT, Thomas Matthews
    > <> 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
    Walter Roberson, Apr 14, 2005
    #9
  10. On 14 Apr 2005 22:53:24 GMT, Walter Roberson
    <-cnrc.gc.ca> wrote:

    > In article <>,
    > Chris Croughton <> wrote:
    >>On Wed, 13 Apr 2005 20:50:36 GMT, Thomas Matthews
    >> <> 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.)


    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
    Chris Croughton, Apr 15, 2005
    #10
  11. In article <>,
    Chris Croughton <> wrote:
    >On 14 Apr 2005 22:53:24 GMT, Walter Roberson
    > <-cnrc.gc.ca> wrote:


    >>>On Wed, 13 Apr 2005 20:50:36 GMT, Thomas Matthews
    >>> <> 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.


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

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


    >On any common system?


    Is gcc common? ("Is God famous?")
    --
    Studies show that the average reader ignores 106% of all statistics
    they see in .signatures.
    Walter Roberson, Apr 15, 2005
    #11
  12. -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_Keith) <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.
    Keith Thompson, Apr 15, 2005
    #12
  13. JS

    Simon Guest

    Do note that, confusingly for some, these "object files" have nothing
    to do whatsoever with "object-oriented programming" a la Java or C++.
    Simon, Apr 16, 2005
    #13
  14. On 15 Apr 2005 22:01:52 GMT, Walter Roberson
    <-cnrc.gc.ca> wrote:

    > In article <>,
    > Chris Croughton <> wrote:
    >>On 14 Apr 2005 22:53:24 GMT, Walter Roberson
    >> <-cnrc.gc.ca> wrote:

    >
    >>>>On Wed, 13 Apr 2005 20:50:36 GMT, Thomas Matthews
    >>>> <> 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.

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


    Yes:

    --------------------------------------------------------------------
    From: Thomas Matthews <>
    Newsgroups: comp.lang.c
    Subject: Re: Object files
    Date: Wed, 13 Apr 2005 20:50:36 GMT
    Reply-To:

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

    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.

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

    >
    >>On any common system?

    >
    > 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
    Chris Croughton, Apr 16, 2005
    #14
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page