shared libraries, when to use them

[Guy Harris]

>It is installed with a ".so" suffix, and possibly a version suffix after
>that,

I think the linker may *require* major and minor version numbers; it may
not recognize the file as a library - at least not if you use "-l" -
otherwise.  Start at version 1.0; bump the minor version number every
time you make a change to the library that would cause programs linked
against the new library to possibly fail if run against the old library;
bump the major version number every time you make a change to the
library that would cause programs linked against the old version to fail
when run against the new one.

For example, if you add a new routine to the library, or add a new
capability to an existing routine, bump the minor version number.  If
you change the calling sequence to a routine, or the shape of a
structure you pass (either by value or reference) to a routine, bump the
major version number.

>It is not necessary to run ranlib over a shared library.

Especially given that "ranlib" will say "Hey!  That's an a.out!  I can't
ranlib that!" and bail out.

>I believe it extracts the code from the static libraries that are installed
>for most libraries in addition to the shared libraries (e.g. libc.a has a
>libc.a.so, which is shared, and a libc.a, which is not).

It does.  If dynamic linking (-Bdynamic) is in effect, which it is by
default, a "-lXXX" option will first try to link against "libXXX.so.X.Y"
and, if no such file is found, try to link against "libXXX.a".  If
static linking is in effect, it'll ignore any "libXXX.so.X.Y" files it
finds.

>I'm not certain if the linker is smart enough to use the
>position-independent code from the shared library if a static library
>isn't installed.

It's not.  If static linking is in effect, and there's no
"libXXX.so.X.Y", it fails.