shared libraries - is this the bottomline?

QNX Newsgroups (Archives) comp.os.qnx
#1

Ok, when compiling code, is this the bottomline with regard to shared
libraries:

  • If I created an object file with the -shared option, I can use it in to
    create a shared library or a static libary
  • If I created an object file without the -shared option, I can only use it
    for a static library

Also, what are the disadvantages of using an object file that was compiled
with the -shared option in a static library? I noticed the size of the
executable is bigger.

The reason I am asking is: If I want to create a shared version and a static
version of a library, do I need to compile the code two times with different
options, or can I just compile one time with the shared option?

Thanks a lot
Markus

#2

Markus Loffler <loffler@ces.clemson.edu> wrote:

Ok, when compiling code, is this the bottomline with regard to shared
libraries:

  • If I created an object file with the -shared option, I can use it in to
    create a shared library or a static libary
  • If I created an object file without the -shared option, I can only use it
    for a static library

Also, what are the disadvantages of using an object file that was compiled
with the -shared option in a static library? I noticed the size of the
executable is bigger.

The reason I am asking is: If I want to create a shared version and a static
version of a library, do I need to compile the code two times with different
options, or can I just compile one time with the shared option?

You need to compile it twice. In fact, there are three libraries you
may want to make.

o Fully static

  • used to link with executables only. (libfoo.a)

o Fully dynamic

  • and be used to link against other .so’s and executables. (libfoo.so)

o Shared static

  • used to link with other .so’s. (libfooS.a)

The last two want the -shared option, the first does not.

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

#3

Chris,
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?
Looks like I only need this one if I want to combine a couple of shared libs
into a static one.
Markus


“Chris McKillop” <cdm@qnx.com> wrote in message
news:95481e$bv6$1@nntp.qnx.com…

Markus Loffler <> loffler@ces.clemson.edu> > wrote:
Ok, when compiling code, is this the bottomline with regard to shared
libraries:

  • If I created an object file with the -shared option, I can use it in
    to
    create a shared library or a static libary
  • If I created an object file without the -shared option, I can only use
    it
    for a static library

Also, what are the disadvantages of using an object file that was
compiled
with the -shared option in a static library? I noticed the size of the
executable is bigger.

The reason I am asking is: If I want to create a shared version and a
static
version of a library, do I need to compile the code two times with
different
options, or can I just compile one time with the shared option?


You need to compile it twice. In fact, there are three libraries you
may want to make.

o Fully static

  • used to link with executables only. (libfoo.a)

o Fully dynamic

  • and be used to link against other .so’s and executables. (libfoo.so)

o Shared static

  • used to link with other .so’s. (libfooS.a)

The last two want the -shared option, the first does not.

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

#4

“Markus Loffler” <loffler@ces.clemson.edu> wrote in message
news:954aqm$6kl$1@inn.qnx.com…

Chris,
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
architectural decision.

Looks like I only need this one if I want to combine a couple of shared
libs
into a static one.
Markus

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.

#5

Markus Loffler <loffler@ces.clemson.edu> wrote:

Ok, when compiling code, is this the bottomline with regard to shared
libraries:

  • If I created an object file with the -shared option, I can use it in to
    create a shared library or a static libary
  • If I created an object file without the -shared option, I can only use it
    for a static library

Also, what are the disadvantages of using an object file that was compiled
with the -shared option in a static library? I noticed the size of the
executable is bigger.

Bigger code. Slower code. It has to generate position-independent code,
so you get less optimal code.

-David

QNX Training Services
dagibbs@qnx.com

#6

Markus Loffler <loffler@ces.clemson.edu> wrote:

Chris,
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?
Looks like I only need this one if I want to combine a couple of shared libs
into a static one.
Markus

You are linking a shared lib WITH a static lib, yes. If you make a
normal static lib and link it with the shared library it will crash
because it is assumed that ALL the code found within a shared library
is position independant. We use this @ QSSL for common functions
shared between different drivers. I think you will find a libdrvrS.a
and a libdrvr.a on your system. One is for when we make a driver
a .a and statically link it and the other is for when we make a driver
a .so and dynamically link it.

chris

–

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<