.a vs .o - Linux

This is a discussion on .a vs .o - Linux ; hi all Why we need static library? I can treat an .a file as .o file, like: g++ lib.a b.o g++ lib.o b.o Same result thanks from Peter (cmk128@hotmail.com)...

+ Reply to Thread
Results 1 to 9 of 9

Thread: .a vs .o

  1. .a vs .o

    hi all
    Why we need static library? I can treat an .a file as .o file, like:

    g++ lib.a b.o
    g++ lib.o b.o

    Same result

    thanks
    from Peter (cmk128@hotmail.com)


  2. Re: .a vs .o

    cmk128@hotmail.com wrote:
    > hi all
    > Why we need static library? I can treat an .a file as .o file, like:
    >
    > g++ lib.a b.o
    > g++ lib.o b.o


    a single lib.a can contain multiple lib.o's, ld picks only those lib.o's
    which are needed!
    I'm not sure if ld may skip unneeded lib.o's in
    g++ lib1.o lib2.o lib3.o lib4.o lib5.o lib6.o ...

    --
    Josef Mllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett


  3. Re: .a vs .o


    Josef Moellers 寫道:

    > cmk128@hotmail.com wrote:
    > > hi all
    > > Why we need static library? I can treat an .a file as .o file, like:
    > >
    > > g++ lib.a b.o
    > > g++ lib.o b.o

    >
    > a single lib.a can contain multiple lib.o's, ld picks only those lib.o's
    > which are needed!
    > I'm not sure if ld may skip unneeded lib.o's in
    > g++ lib1.o lib2.o lib3.o lib4.o lib5.o lib6.o ...
    >
    > --
    > Josef Möllers (Pinguinpfleger bei FSC)
    > If failure had no penalty success would not be a prize
    > -- T. Pratchett


    No, we can combine objects:
    ld -r a.o b1.o b2.o b3.o
    So, .a has no advantage than .o?
    thanks
    from Peter


  4. Re: .a vs .o

    In comp.os.linux.development.system cmk128@hotmail.com wrote:
    |
    | Josef Moellers ???
    |
    |> cmk128@hotmail.com wrote:
    |> > hi all
    |> > Why we need static library? I can treat an .a file as .o file, like:
    |> >
    |> > g++ lib.a b.o
    |> > g++ lib.o b.o
    |>
    |> a single lib.a can contain multiple lib.o's, ld picks only those lib.o's
    |> which are needed!
    |> I'm not sure if ld may skip unneeded lib.o's in
    |> g++ lib1.o lib2.o lib3.o lib4.o lib5.o lib6.o ...
    |>
    |> --
    |> Josef M?llers (Pinguinpfleger bei FSC)
    |> If failure had no penalty success would not be a prize
    |> -- T. Pratchett
    |
    | No, we can combine objects:
    | ld -r a.o b1.o b2.o b3.o
    | So, .a has no advantage than .o?

    My library has hundreds of .o files in it. The .a file is a big advantage.
    You wouldn't want to do this with libc, now would you?

    phil@canopus:/home/phil 356> ar t /usr/local/lib/libh.a | wc -l
    746
    phil@canopus:/home/phil 357> ar t /usr/lib/libc.a | wc -l
    1303
    phil@canopus:/home/phil 358>

    I'm not even sure if ld will omit unneeded .o files if one does put any
    unreferenced .o files on the command line. It certainly won't include
    what is not needed from a .a file.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2006-11-02-1236@ipal.net |
    |------------------------------------/-------------------------------------|

  5. Re: .a vs .o


    cmk128@hotmail.com wrote:
    > hi all
    > Why we need static library? I can treat an .a file as .o file, like:


    Why do we need tar? We can upload and download individual files.

    > g++ lib.a b.o
    > g++ lib.o b.o
    >
    > Same result


    To create a single lib.o out of all the .o modules that are in lib.a
    you have to perform a partial link.

    One problem with that is that you can't extract the individual modules
    any more.

    Another problem with that is that the linker cannot throw away modules
    which are not used.

    So a better question is, why:

    ar crs libfoo.a module1.o module2.o ... modulen.o
    g++ -lfoo

    versus

    g++ module1.o module2.o ... modulen.o

    There are many answers possible.

    One is that libraries unify a set of modules into a single unit. If you
    have an archive library called "libfoo.a" installed in a directory
    which is in the library search path, then you can link it using
    "-lfoo". Without this feature, you would have to cite the name of every
    single one of the object files. The number and even spelling of those
    names would vary from one revision of the library to the next.

    Another answer is that the linker can deal with archives more
    efficiently. It can assume that there are no cyclic dependencies among
    the archives. (If this is not the case, you have to override it using
    special command line syntax). That is to say, if you link

    gcc libfoo.a libbar.a libxyzzy.a

    the linker will assume that libfoo calls libbar, and libbar calls
    libxyzzy. Whereas if you were to present all of the object files
    individually on the command line, the linker would have to consider
    them all together and look for calls from any object file to any object
    file. That is to say, by default, an archive on the command line will
    satisfy unresolved references from object files earlier on the command
    line, but it will not be considered for satisfying unresolved
    references in objects or archives later on the command line. If you
    are making some huge program, having it split up into a non-cyclic tree
    of archives could make a big difference to the link time, since the
    linker can basically process the archives one by one in one pass, and
    backpatch earlier references as it encounters their resolutions.


  6. Re: .a vs .o

    phil-news-nospam@ipal.net writes:
    > I'm not even sure if ld will omit unneeded .o files if one does put any
    > unreferenced .o files on the command line.


    Traditionally it doesn't (doesn't omit unneeded files), so there's some
    advantage to putting your own .o files into temporary .a archives (in
    the build directory) for linking. If you lots of conditional
    compilation etc., it's much easier to just let the linker figure things
    out than to doing so yourself.

    -Miles
    --
    `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
    `All the past could be forgiven.' [NYT]

  7. Re: .a vs .o

    In comp.os.linux.development.system Miles Bader wrote:
    | phil-news-nospam@ipal.net writes:
    |> I'm not even sure if ld will omit unneeded .o files if one does put any
    |> unreferenced .o files on the command line.
    |
    | Traditionally it doesn't (doesn't omit unneeded files), so there's some
    | advantage to putting your own .o files into temporary .a archives (in
    | the build directory) for linking. If you lots of conditional
    | compilation etc., it's much easier to just let the linker figure things
    | out than to doing so yourself.

    All the more reason to do it exactly as I have been doing it all along,
    which is to put the .a file on the command line, and almost never a .o
    file.

    It would be nice if ld could accept a directory on the command line and
    look for useable .o files within that directory. But .a files index the
    symbols, so using a .a file is certainly faster linking.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2006-11-02-2327@ipal.net |
    |------------------------------------/-------------------------------------|

  8. Re: .a vs .o

    In comp.os.linux.development.system Kaz Kylheku wrote:

    | So a better question is, why:
    |
    | ar crs libfoo.a module1.o module2.o ... modulen.o
    | g++ -lfoo
    |
    | versus
    |
    | g++ module1.o module2.o ... modulen.o
    |
    | There are many answers possible.
    |
    | One is that libraries unify a set of modules into a single unit. If you
    | have an archive library called "libfoo.a" installed in a directory
    | which is in the library search path, then you can link it using
    | "-lfoo". Without this feature, you would have to cite the name of every
    | single one of the object files. The number and even spelling of those
    | names would vary from one revision of the library to the next.
    |
    | Another answer is that the linker can deal with archives more
    | efficiently. It can assume that there are no cyclic dependencies among
    | the archives. (If this is not the case, you have to override it using
    | special command line syntax). That is to say, if you link
    |
    | gcc libfoo.a libbar.a libxyzzy.a
    |
    | the linker will assume that libfoo calls libbar, and libbar calls
    | libxyzzy. Whereas if you were to present all of the object files
    | individually on the command line, the linker would have to consider
    | them all together and look for calls from any object file to any object
    | file. That is to say, by default, an archive on the command line will
    | satisfy unresolved references from object files earlier on the command
    | line, but it will not be considered for satisfying unresolved
    | references in objects or archives later on the command line. If you
    | are making some huge program, having it split up into a non-cyclic tree
    | of archives could make a big difference to the link time, since the
    | linker can basically process the archives one by one in one pass, and
    | backpatch earlier references as it encounters their resolutions.

    In addition to not needing to scan the symbol tables of every .o file
    just to see which have needed symbols. The archive has an index table
    that speeds up the selection.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2006-11-02-2332@ipal.net |
    |------------------------------------/-------------------------------------|

  9. Re: .a vs .o


    cmk128@hotmail.com wrote:

    > No, we can combine objects:
    > ld -r a.o b1.o b2.o b3.o
    > So, .a has no advantage than .o?
    > thanks
    > from Peter


    This creates one giant .o file, having none of the advantages of .a
    files. For example, a .a file has an index that permits rapid linking.
    A .a file has the ability to discard unneeded modules at link time.

    DS


+ Reply to Thread