|
Home > Archive > Unix Programming > January 2004 > What's different between Library (.a) and Shared object (.o)?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
What's different between Library (.a) and Shared object (.o)?
|
|
|
| What's different between Library (.a) and Shared object (.o)?
| |
| Fletcher Glenn 2004-01-27, 9:35 am |
|
Nick wrote:quote:
> What's different between Library (.a) and Shared object (.o)?
The primary difference between a .a and a .so library is that the
executables in the .so library have been compiled as Position
Independent Code (PIC). This means that the executables can be
loaded anywhere in memory mostly because there are no absolute
references.
--
Fletcher Glenn
| |
| Jens.Toerring@physik.fu-berlin.de 2004-01-27, 9:35 am |
| Nick <nbdy9@hotmail.com.nospam> wrote:quote:
> What's different between Library (.a) and Shared object (.o)?
..o files (typically) are object files, i.e. the output of the compiler.
Usually several object files are linked together to make an executable.
..a files are static libraries. They aren't much more than a collection
(an "archive", that's where the 'a' comes from) of object files. They
can get linked together with one or more object file to make the final
program.
..so files are shared libraries. Basically, they also consist of object
files. But in contrast to static libraries, that get linked permanently
to an executable (become part of the executable after linking), they
only get added to the copy of executable in memory when it's run. The
executable contains just some information about which shared libraries
it needs to be run but not the whole code.
This can have several advantages. First of all, the executables are
smaller, you don't have to store the content of a static library
together with the executable. And since a libraries tend to get to
linked to a lot of programs you don't need to store maybe hundreds
of copies of the basically the same code (one for each program
linked against the static library) but only a single copy. Second,
since these shared libraries aren't integrated into the executable
you can install a new, improved version of a library and all already
existing executables using that library automatically get the new
version without the need to recompile all of them (as it would be
the case with static libraries). Finally, programs can also load
shared libraries while they are already runnig, allowing you to
create plug-ins that only get loaded on demand (and can be easily
be replaced without modifications to the program using them).
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.physik.fu-berlin.de/~toerring
| |
| Jerry Feldman 2004-01-27, 11:35 am |
| On Tue, 27 Jan 2004 16:07:44 -0500
Nick <nbdy9@hotmail.com.nospam> wrote:
quote:
> What's different between Library (.a) and Shared object (.o)?
Just to add to Fletcher and Jens comments:
When you link with an archive library (.a), its contents are included in
your executable program. The advantage is that your code is not
dependent on the shared libraries being available. The downside is that
your executable it large.
When you link with a shared library (or more appropriately a shared
object), that library does not become part of your executable, and that
library may be shared among many other programs that use it. Typically,
there will be a single instance of the shared object resident in memory.
The advantage is your program is smaller, and in many cases will load
faster. A shared library can be updated without you needing to recompile
your code.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
| |
| Paul Pluzhnikov 2004-01-27, 4:34 pm |
| Fletcher Glenn <fletcher@removethisfoglight.com> writes:
quote:
> Nick wrote:
>
> The primary difference between a .a and a .so library is that the
> executables in the .so library have been compiled as Position
> Independent Code (PIC).
If you think this is the *primary* difference, you are quite mistaken:
while it is true that shared libraries are usually built from PIC code,
there are valid (performance) reasons to do otherwize, and NVidia
libGL.so for Linux is built from non-PIC code.
Further, on some platforms (e.g. AIX) all code is always PIC, yet there
is still a big difference between an object file and a "shared
object module".
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
|
|
|
|
|