“Markus Loffler” <firstname.lastname@example.org> wrote in message
thanks for the info. Can you ellaborate on
o Shared static
- used to link with other .so’s. (libfooS.a)
Is it that I’m linking shared libs to a static lib… because I may only
have shared libs available?
IMO “libfooS.a” wouldn’t be an arbitrary decision, but a deliberate
Looks like I only need this one if I want to combine a couple of shared
into a static one.
I think you want a libfooS.a, if you have some code that is utilized by
multiple shared objects, and which you want directly linked into those
shared objects (i.e. not a shared object of it’s own). I can think of
several examples where this would be useful. One example would be where you
produced a number of embedded systems, all of which contained a shared
object that performed function “bar”, and which required service “foo”, but
service “foo” (which has a standard interface) has code unique to the
environment of each of the embedded systems, and is not shared with any
other shared objects or applications that would exist on a particular
instance of an embedded system. Rather than make “foo” another shared
object (which requires additional overhead), you compile “foo” with position
independent code, and statically link it (i.e. libfooS.a) into (what
becomes, after linking) your system dependent version of “bar” for each of
the systems you ship.
By designing the system this way, you lose nothing configuration management
wise (you have 1 system dependent shared object either way), but you
maintain the software architecture of “bar” being the system independent,
module, and “foo” being the system dependent module. If “bar” is a
significantly larger amount of code than “foo” (typical), then this is a win
(vs. writing several different - or worse - ifdef’d versions of “bar”). The
win at runtime is the little bit of ROM and RAM saved by not having two
shared objects which is clearly a minor advantage, but sometimes every
little bit counts, especially when it really doesn’t cost anything.