[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: shared libs question (overlooked in freebsd-questions)
From:       Alfred Perlstein <bright () hotjobs ! com>
Date:       1998-12-31 9:06:24
[Download RAW message or body]


On Wed, 30 Dec 1998, Andrew wrote:

> Hello all,
>  
> I am curious to find out if anyone can explain shared libs...
>  
> Background; when compiling tcp_wrappers-7.6 from source
> libwrap.a is created.  In the FreeBSD port, however, there
> is an additional lib, libwrap.so.7.6 (and a symblink to it
> from libwrap.so).
> 
> OK, my question, what is the difference between libwrap.a
> and libwrap.so.7.6, under what circumstances is each one
> used, and how do I create libwrap.so.7.6 from sources?

.so files are shared objects, when a program is 'linked' to them, all that
happens is that a little piece of code in attached to your program, when a
function or variable from the .so is referenced the tiny bit of code is
called and the shared object is loaded to resolve the function/variable in
the shared object.

.a files are mearly pre-compiled object files 'mashed' into an archive,
when you link against them, code that resolves to individual .o file
included in the .a (archive) is copied into your program (no 'runtime'
linking is done)

some reasons for picking one option over the other:

.a vs .so
1) your program really can't be dynamically linked, ie. a kernel
2) you have a library for modularity sake, but only one program on the
system is likly to use it
3) small speed advantage

.so vs .a
1) many programs use the library, because of this you:
   a) save space (they all share one .so)
   b) save execution time if many seperate programs are being run that
      use the same libraries (for instance a heavily loaded web site
      running a lot of CGI programs that share common routines) because
      of smaller text segment. (really better shared)
   c) save memory
   d) if you update the .so and move it over the old one, all programs will
      now be updated, so if a bug is found in the library, you don't have
      to relink all your programs, just recompile the shared object and
      drop it in.

I'm sure there are other reasons, as an argument for each, generally
.a (archives) are useful if the library isn't used throughout the system
and .so are if the library is used by many applications.

Generally unless told otherwise the defualt behavior of the compilers and
linkers is to try to link against .so first and then try .a

Does this help?
Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com
-- There are operating systems, and then there's FreeBSD.
-- http://www.freebsd.org/                        3.0-current

> 
> 
> Cordially,
> _____________________________________________
> Andrew Perkins              andrew@violet.org
> System Administrator             415.739.0540
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message

[prev in list] [next in list] [prev in thread] [next in thread]