Menu
I understand that code included in an executable at compile-time can come from object files (.o files) and statically-linked libraries (.lib/.a files). What is fundamentally and conceptually the difference between these two? Why is there a different concept between "object code" and a "statically-linked library"? What are the advantages and disadvantages to each, and why use one as opposed to the other? Can statically-linked library(ies) be made from object file(s), and vise-versa, can object file(s) be made from statically-linked library(ies)?
820
Static libraries take longer to execute, because loading into the memory happens every time while executing. While Shared libraries are faster because shared library code is already in the memory. In Static library no compatibility issue has been observed.
What are the differences between static and dynamic libraries? Static libraries, while reusable in multiple programs, are locked into a program at compile time. Dynamic, or shared libraries, on the other hand, exist as separate files outside of the executable file.
An object file is a computer file containing object code, that is, machine code output of an assembler or compiler. The object code is usually relocatable, and not usually directly executable. There are various formats for object files, and the same machine code can be packaged in different object file formats.
Definition. Static linking is the process of copying all library modules used in the program into the final executable image. In contrast, dynamic linking is the process of loading the external shared libraries into the program and then binds those shared libraries dynamically to the program.
Object files are compiled but unlinked code. Libraries contain object files. Thus your question becomes, "Why use statically-linked libs if I can just use object files?" Here's why.
Unlike a collection of objects, each of which have their own symbol tables, a library has a single, unified symbol table, created when ar is called by the library developer using the s switch. s calls ranlib to create a unified symbol table for all objects in that archive.
Running ranlib in shell shows in the first line of help text:
Generate an index to speed access to archives.
And from the generic ranlib docs:
An archive with such an index speeds up linking to the library and allows routines in the library to call each other without regard to their placement in the archive. T
See also the FreeBSD ranlib docs - different wording, same idea: Speed of linkage.
84
A library is simply a file containing many object files, which can be searched to resolve symbols.
So typically, when you link objects together, you get all the objects in one executable (though some optimising linkers can throw out unused ones).
When you give a library to the linker, it examines each of the object files within it and brings in those that are needed to satisfy unresolved symbols (and will probably continue to bring them in until either all symbols are resolved or no more can be).
It's just a way of efficiently packaging up a lot of objects into a single file so that the linker can do more of your work - you don't have to worry about which objects you need.
If you think of the C library, you may have a printf.o, puts.o, fopen.o as a result of keeping your source well separated. You don't want the user to have to explicitly list every single object file they want so you package the whole lot up into libc.a and tell them they just need to link with that single file.
The statically-linked bit is irrelevant here, it just decides that the objects should go into the executable at link time rather than being dynamically loaded at run time. It's explained here.
44
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
