0

In reference to this answer:

There are two Linux C/C++ library types.

  • Static libraries (*.a) are archives of object code which are linked with and becomes part of the application. They are created with and can be manipulated using the ar(1) command (i.e. ar -t libfoo.a will list the files in the library/archive).

  • Dynamically linked shared object libraries (*.so) can be used in two ways.

    1. The shared object libraries can be dynamically linked at run time but statically aware. The libraries must be available during compile/link phase. The shared objects are not included into the binary executable but are tied to the execution.
    2. The shared object libraries can be dynamically loaded/unloaded and linked during execution using the dynamic linking loader system functions.

what does it mean to make a dynamic lib tied to the execution?

Is this like Windows manifest files that allow the application to load in a specific dll?

What's the mechanism to control the .so loaded?
There must be such a mechanism otherwise the "compiled" .so is the only one ever allowed to be loaded which defeats the purpose of making it dynamic?

Community
  • 1
  • 1
Bob
  • 4,576
  • 7
  • 39
  • 107
  • In Windows, a potentially simpler-to-understand equivalent would be an [*import library*](https://msdn.microsoft.com/en-us/library/windows/desktop/ms682592(v=vs.85).aspx), generated from a module definition file or dll, and linked against whatever module(s) want to pull in the module in question. – WhozCraig Oct 21 '16 at 16:00
  • @WhozCraig can you recommend a site that, with diagrams, explains how Linux app loads and uses a **.so** file? – Bob Oct 21 '16 at 16:05

1 Answers1

0

It means that the library is available at link time, so the linker can verify that the functions that you reference from the .so are present in the .so. The advantage is that calls to these functions are done transparently to you. In other words, if you are linking to an .so with

int foo(double bar);

you call it like this

int res = foo(4.2);

The linker makes sure that foo is there, and that it takes one argument of type double. After that it "links" the call site int res = ... to the function.

Dynamically loading/unloading during the execution time lets you link without .so present on the build system (hence, no "static awareness"). In exchange for this added flexibility you open your system up to a possibility of not finding the functions that you want in the target .so. Your calls sequence also look considerably trickier than foo(4.2), because you need to go through dlopen preparation step. More info on calling functions from .so is in this Q&A.

Community
  • 1
  • 1
Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523